[XeTeX] Version 0.5 available

[Ross Moore]

On 01/05/2004, at 6:35 PM, Jonathan Kew wrote:

> Hi Ross,
>
> Thanks for your experiments and notes. Don't spend more time trying to 
> "fix" your xetex.def on top of the current \XeTeXpicfile; better to 
> help me understand what \includegraphics does, and see if I can make 
> things easier. (Can you point me to a concise description of how the 
> \includegraphics options are processed? I haven't touched LaTeX since 
> about 1989, so this stuff is completely foreign to me!)
>
> Just FYI, here's what \XeTeXpicfile currently does (or at least tries 
> to do); clearly, it's a different model than \includegraphics.

Yep --- I've been trying to wrap my head around it,
and trying to make sense of it myself.
In fact it is quite logical, given the ability to
specify individual transformations, rather than trying
to specify the result of a series of transformations.


I'll explain my conclusions, rather than pointing you to
documentation.

Firstly, there are 3 basic operations:

  1.  scaling by a constant factor;
  2.  scaling by different amounts in the x- and y-directions
  3.  rotating through an angle (from bottom-left corner).

(In fact \includegraphics allows for shifting the center
  of rotation to anywhere else; but let's forget that aspect
  for this discussion.)


Here's how to interpret a sequence of options.

  a.  start with the natural size of the contents
       (e.g. the size of the imported image)
      and calculate its aspect-ratio;

  b.  read left to right;

  c.  when you encounter either:
         angle=
         scale=
         end-of-options
      then we need to recalculate the size of the rectangle,
      (and aspect-ratio) *before* doing the rotation/scaling
      or setting the final size.

"recalculating the size" is done by:

   (i)   if neither width=  nor  height=  has occurred
         since the previous recalculation, use the current sizes;

   (ii)  if  width=... has occurred since the previous recalculation,
         use it as the new width;

  (iii)  if  height=... has occurred since the previous recalculation,
         use it as the new height;

   (iv)  if either height or width has *not* occurred then get its new
         value from the other, using the aspect-ratio.


   d.  do the specified  scale/rotate  command, and calculate
       the new size and aspect-ratio;

   e.  continue with step c. until the sequence is exhausted.



>
> 1) if height and width are specified anywhere in the options, the 
> graphic is initially scaled to this size, before other transformations

No. The role of  height=  and  width=  is to set values *between*
each  scale/angle  option.  The there is more than one occurrence,
these can be used for different transformations.


> 1.a) if height or width is specified more than once, the later value 
> wins

   ... only if there has been no  scale/angle  in-between.

>
> 1.b) if only one of height and width is specified, the other dimension 
> is scaled in proportion; if both are specified, you get (potentially) 
> non-proportional scaling

    Yes; that's correct.
    But it holds between each scale/angle , not overall.

>
> 2) after handling explicit height/width to set the initial image size, 
> other transformations are applied to the graphic in the order 
> specified

   no; the above description gives the true(?) story.

>
> I'll see if I can get some understanding of how \includegraphics 
> resolves conflicting or ambiguous combinations of options, and look 
> into modifying XeTeX to make it easier to implement the LaTeX stuff on 
> top.

In pdftex, the PDF coding for each transformation is wrapped around
the coding for the contents. Same for PostScript, using dvips.

Thus the left -> right sequence of transformations is actually 
implemented
from the inside out. The *real* work is then done by the PostScript/PDF
interpreter and associated rendering engine.

With this model, you can see that it applies unchanged to whatever are
the original contents being transformed --- provided the means to create
the necessary coding for the transformations are available.



That's my understanding of how it works.
I hope it'll be useful to you.


Cheers

	Ross


>
> Jonathan
>
> _______________________________________________
> XeTeX mailing list
> postmaster at tug.org
> http://tug.org/mailman/listinfo/xetex
>
------------------------------------------------------------------------
Ross Moore                                         ross at maths.mq.edu.au
Mathematics Department                             office: E7A-419
Macquarie University                               tel: +61 +2 9850 8955
Sydney, Australia                                  fax: +61 +2 9850 8114
------------------------------------------------------------------------