[OS X TeX] Re: [XeTeX] XeTeX incorrectly scales JPEG and other graphics files

[Peter Dyballa]

Am 13.09.2008 um 01:45 schrieb Akira Kakuto:

>> 	diff playloud.xbb playloud.bb
>> 	3,4c3,4
>> 	< %%BoundingBox: 0 0 85 40
>> 	< %%CreationDate: Sat Sep 13 00:18:46 2008
>> 	---
>> 	> %%BoundingBox: 0 0 297 140
>> 	> %%CreationDate: Sat Sep 13 00:17:44 2008
>
> I cannot understand this.
> For bitmap graphics, I think
> (ebb value) = (xbb value) * 72 / 100.


ImageMagick's identify tells about the image:

	playloud.jpg JPEG 413x194 413x194+0+0 8-bit DirectClass 32.2617kb


Extractbb can work verbosely (-v), which means it echos to stdout  
what it writes to the file. And it has two modes (besides a binary  
one) to record information:

	-m	Output .bb  file used in DVIPDFM
	-x	Output .xbb file used in DVIPDFMx (default)

Let's see how it works!

pete 297 /\ l playloud.*bb
tcsh: /sw/bin/gls: No match.				# a clean start!
Exit 1
pete 298 /\ extractbb -vm playloud.jpg
Writing to ./playloud.xbb: Bounding box: 0 0 85 40	# .bb is documented!
pete 299 /\ l playloud.*bb
-rw-r--r-- 1 pete admin 124 13. Sep 13:30 playloud.xbb	# .bb is  
documented!
pete 300 /\ cat playloud.xbb
%%Title: ./playloud.jpg
%%Creator: extractbb Version 0.2
%%BoundingBox: 0 0 85 40
%%CreationDate: Sat Sep 13 13:30:06 2008

pete 301 /\ extractbb -vx playloud.jpg
Writing to ./playloud.xbb: Bounding box: 0 0 85 40
pete 302 /\ l playloud.*bb
-rw-r--r-- 1 pete admin 124 13. Sep 13:30 playloud.xbb	# too fast ...
pete 303 /\ cat playloud.xbb
%%Title: ./playloud.jpg
%%Creator: extractbb Version 0.2
%%BoundingBox: 0 0 85 40
%%CreationDate: Sat Sep 13 13:30:37 2008		# new time at least

pete 304 /\ extractbb -m playloud.jpg
pete 305 /\ l playloud.*bb
-rw-r--r-- 1 pete admin 126 13. Sep 13:31 playloud.bb	# ah! as  
documented
-rw-r--r-- 1 pete admin 124 13. Sep 13:30 playloud.xbb
pete 306 /\ cat playloud.bb
%%Title: ./playloud.jpg
%%Creator: extractbb Version 0.2
%%BoundingBox: 0 0 297 140				# other dimensions ...
%%CreationDate: Sat Sep 13 13:31:53 2008

pete 307 /\ extractbb -x playloud.jpg
pete 308 /\ l playloud.*bb
-rw-r--r-- 1 pete admin 126 13. Sep 13:31 playloud.bb
-rw-r--r-- 1 pete admin 124 13. Sep 13:32 playloud.xbb	# OK, as  
documented
pete 309 /\ cat playloud.xbb
%%Title: ./playloud.jpg
%%Creator: extractbb Version 0.2
%%BoundingBox: 0 0 85 40				# stable values!
%%CreationDate: Sat Sep 13 13:32:45 2008


Ebb has at least a manual page, a short one. It also has the ability  
to work verbosely and also has a binary mode. Let's see it work OK:

pete 316 /\ ebb -v playloud.jpg
Writing to ./playloud.bb: Bounding box: 0 0 297 140
pete 317 /\ l playloud.*bb
-rw-r--r-- 1 pete admin 126 13. Sep 13:45 playloud.bb
pete 318 /\ cat playloud.bb
%%Title: ./playloud.jpg
%%Creator: extractbb Version 0.2
%%BoundingBox: 0 0 297 140
%%CreationDate: Sat Sep 13 13:45:56 2008

In case of ebb, assuming a default resolution of 72 DPI, it assumes  
the JPEG image is 100 DPI. Then the ebb dimensions are 72/100 of the  
values identify tells. More verbosely identify and Apple's sips (sips  
-g dpiHeight -g dpiWidth -g pixelHeight -g pixelWidth -g  
samplesPerPixel -g bitsPerSample -g typeIdentifier -g format -g  
formatOptions -g hasAlpha playloud.jpg) tell (an excerpt):

   dpiHeight: 350.000
   dpiWidth: 350.000
   pixelHeight: 194
   pixelWidth: 413

Extractbb's values are each a fifth of the picture's dimensions, so  
it obviously reads the picture's actual resolution and computes its  
data, scaled to 72 DPI, on real numbers, not assumptions.


I'll report extractbb's bug with -v to tex-live! And I'll also  
mention that ebb identifies itself in the BB file as extractbb  
(although it makes diff's output clearer).

One more thing: I don't see an xbb programme ...

--
Greetings

   Pete
                       ~  o
                        ~_\\_/\
                       ~  O   O