[XeTeX] XeTeX 0.4 available

[Ross Moore]

Hi Hans, Jonathan,

On 22/04/2004, at 2:52 AM, Hans Hagen wrote:

> At 18:32 21/04/2004, Jonathan Kew wrote:
>
> A couple of questions (for you to think about in the morning; others 
> are of course welcome to offer opinions as well!):
>
>> * Should there also be cropping options on \picfile? I've always done 
>> stuff like that outside of TeX, but I remember someone mentioning it; 
>> does \includegraphics have cropping facilities? If so, what would be 
>> a logical approach to extending \picfile: four new keywords - 
>> cropleft, cropright, croptop, cropbottom? How should this interact 
>> with scaling and rotation?
>
> normally that (scaling, rotating, cropping, mirroring, etc) are 
> handled indepdent of the graphics, think of a graphic being part of a 
> box with other content and the whole being scaled; if one can crop 
> text, one can also crop an image so there is no real need for that 
> feature
>
> (one can write postscript specials that provide cropping; or in 
> pdftex/dvipdfmx pdf literals)

Yes; but in XeTeX there is no such ability yet.
XeTeX does not allow you to directly construct PDF coding,
and there is no PostScript --> PDF conversion step, to get it that way.

Hans, you mentioned in a previous email that you were glad to have 
eliminated
use of 'pdfmark' --- but surely that is going to be the simplest way 
forward
if XeTeX is to acquire direct creation of PDF. It will need to be able
to process pdfmarks internally, to be able to build consistent PDF pages
incorporating the results of macro-packages that exist already.


Back to cropping, scaling, etc.
These occur in the options to \includegraphics, so are naturally 
thought-of
as being applicable just to the imported graphic, at least in that 
context.

If there was the ability to do clipping and geometric transformations
of the material within arbitrary boxes, then yes this is a way to 
implement
those options to \includegraphics .

But while there is not such a general method, and there may be an easy 
way
to do these things for single images, then that's the current question.
What we really need to see is documentation on the interfaces that
Jonathan is using, so as to find what is easy to implement, and what is 
not.



>
>> * How badly do people want \special{x:pagecolor=XXXXXX} or similar? 
>> To implement this, I really need to know the page color at the very 
>> beginning of the page, so I can paint it first--which will mean 
>> scanning the page for occurrences of this \special before starting to 
>> image anything. That will have a small but perhaps noticeable cost.
>
> hm, no real need, i.e. what is a page; also macro packages can handle 
> that rather well; keep in mind that when only one system provides 
> that, and when it's not part of the tex concept, that it will not 
> really be used; normally support for that is supported by a macro 
> package kernel, and that kernel operates independent of features of 
> drivers;  forinstance, when a macro package keeps track of such 
> things, support for your driver means that one has to adapt quite a 
> lot (and in doing that in the proper way, i.e. hooks, configurable, 
> etc etc, is not worth the effort when it is already possible by other 
> means. So ... i'd say ... give it low priority.
>
> Also, what is page color: the whole page? the text area? .. tex does 
> not have such concepts, macropackages do -)

Yes, XeTeX should not be drawing a coloured page to implement this.
It should be done by constructing the PDF coding to declare the colour
of the page. This should then follow naturally from the ability to
handle more general PDF constructions by "other means",
such as via the 'pdfmark' mechanism, or by an even more general
mechanism for building and indexing PDF objects with references
between objects.

But this is going beyond Jonathan's stated aim of being
  "simple to use the advanced typography features of OS X"
  --- though ultimately we would like to get there.


Hans, what do you think will be easiest in the short term,
and best in the long-term ?

I think that 'pdfmark' should be do-able, at least for short-term,
and that complete integration with pdfTeX could be a long-term goal.



Best regards

	Ross


>
> Hans
>
> _______________________________________________
> 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
------------------------------------------------------------------------