[XeTeX] Polytonic greek and XeLaTeX

[Ross Moore]

Hi Peter (and others interested in this thread).

On 01/01/2008, at 9:41 PM, Peter Dyballa wrote:

>
> Am 31.12.2007 um 01:13 schrieb Johannes Engel:
>
>> This one is a composed one: Ὀ (i.e. a capital Omicron and a  
>> psili),
>> this one is a prepared one: Ὀ (i.e. one letter Omicron with psili).
>
>
> I think the problem is the so-called composed character: it is indeed
> two characters (as seen in some editors), a capital Omicron and a
> psili. Could this be handled by xunicode.sty?

No, not really. That would require making some characters *active*,
then looking at what comes next, to be able to decide what to do.
This is what Babel does for legacy TeX support of different languages
using 7- (ascii) or 8-bit latin-based encodings. It is an ugly solution,
fraught with all kinds of potential compatibility disasters, which
should no longer be needed with Unicode input.

> It "fixes" already
> composed characters from the Latin script area ...

  xunicode  provides fixes only in the sense of redefining existing
macros to give Unicode output that  XeLaTeX can now work with.

In the situation here there are no macros to be redefined.
Instead we have sequences of Unicode characters; well, a pair of them.
The font is supposed to have support for such pairs, resulting in the
correct glyph being shown.

If this doesn't work with Minion Pro, yet it contains the correct glyph
at a different code-point, then what you want is to specify an  
appropriate
*font-mapping* as part of the command used to declare the font.

This way the solution is tied to the font itself, which is ultimately
the reason why there is a problem.
(Jonathan will surely correct me if this is not the right approach.)


You may wish to consider using other fonts for the Greek text.
So here I've been looking at how well this situation is supported
by the GFS fonts, which were announced on this list some weeks ago.

I've attached an appropriate test document...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: porson.tex
Type: application/octet-stream
Size: 4501 bytes
Desc: not available
Url : http://tug.org/pipermail/xetex/attachments/20080102/b7f1b09f/attachment-0001.obj 
-------------- next part --------------


... and an image of a portion of its typeset output, prepared
using XeTeX 0.996 on a Mac, with  xdvipdfmx version 0.4.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Picture 26.png
Type: image/png
Size: 164544 bytes
Desc: not available
Url : http://tug.org/pipermail/xetex/attachments/20080102/b7f1b09f/attachment-0001.png 
-------------- next part --------------



In doing this, I discovered some interesting things, which may be
regarded as bugs or deficiencies in either the fonts or system/editor
software or in parts of XeTeX.
(Or maybe it's in the way I'm using them.)


Firstly, note that some of the fonts do not support the 'psili'
character as a bare character, but do support pre-composed glyphs.
You can see the anomalies in the attached image, when using
GFS Baskerville and GFS Bodoni variants.


When both methods are supported, the lines beginning 'decomposed'
show the result of "Omega + combining comma" (i.e.  U+039F;U+0313;)
appearing three times on the line, with the 4th instance being
'Omega with psili'  (i.e. U+1F48; ). The difference is usually visible.

Lines beginning 'pre-prepared' also use  \addfontfeature{Script=Greek}
so all three instances appear to be the same, with the 1st and 3rd
being a single character and the 2nd using the combining character.


When the 'combining comma' is not supported the output has a visible
anomaly, when using  xdvipdfmx .  (In these cases  xdv2pdf  actually
crashes with a segmentation fault.)



Another quirk that I found relates to how the
  "Omega + combining comma" combination is created.

When it is copy/pasted from Johannes Engel's original example,
it works fine (modulo the font problems discussed above).

However, I also obtained the 2 pieces for it using the "Characters"
palette under MacOS X 10.4 (i.e., Tiger, not Leopard).
When done this way, the 2 characters show separately within
TeXshop's editor window, so there is no combined character glyph.
Using another editor (Alpha or TextEdit, say) it can be seen that
there is a space appearing between the 2 characters, though this
cannot be detected using TeXshop. Remove it in the other editor.
Now typeset and the combined character indeed results.

However, if further edits are made using TeXshop, the intervening
space returns, so that typesetting gives separate characters again.
Touching up every time in Alpha is a real nuisance.
Surely there is a bug here in TeXshop's editor, or its methods
for saving UTF8 files.



Hopefully someone will find the results of this testing
to be useful, and will repeat it using  XeTeX 0.997
and later versions of  xdvipdfmx  and  xdv2pdf .



Cheers, and Happy New Year,


	Ross



>
> --
> Mit friedvollen Grüßen
>
>    Pete
>
> When in doubt, use brute force.
> 				– Ken Thompson
>
>
>
> _______________________________________________
> 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  2109                            fax: +61 +2 9850 8114
------------------------------------------------------------------------