Re: [XeTeX] Contextual shaping

[Paul Isambert]

"Simon Cozens" :
> This is possibly a daft question, but...
> 
> In traditional TeX, character tokens are processed and put into boxes
> individually, with fairly primitive ligature tables. Obviously XeTeX
> doesn't
> do this, using Harfbuzz (or ICU or whatever) to do the shaping and
> layout.
> 
> My question is, if you're not "showing" individual characters to the
> shaping
> engine for it to consider, what defines how big a string of
> characters to
> shape at a time? Does XeTeX break at the "word" level and then shape
> a word,
> and if so what defines a word? (Chinese has no word breaks!) Or does
> it shape
> an entire paragraph of text at a time (!) and then box up the glyphs
> individually? Or...?
> 
> (I've tried starting at layoutChars in XeTeXLayoutInterface.cpp and
> working
> backwards but I can't understand where I end up: measure_native_node
> shapes a
> node, but what's a node?)

I don't know how Harfbuzz and/or ICU work exactly, but:

- Characters are never put into individual boxes;
- Whatever shaping must take place is defined by sequences of characters; so
you look at each character, see if it must be processed (possibly as a part
of a larger sequence), move to the next character (unless it has been
processed as part of a sequence), and so on. Most of the rules you must follow
to process glyphs are explained here:
http://www.microsoft.com/typography/otspec/
So your question (as I understand it) is really about processing OT fonts. The
sequence of characters I have mentionned (your string of characters) are
defined in the font itself (for complex sequencess, see e.g. contextual 
lookups).

As for a node, it is whatever TeX processes internally to build a page: it can
be a character, a kern, a whatsit, a box...

Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] M'aidez, SVP : ** WARNING ** Version of PDF file (1.6) is newer than version limit specification.

[Paul Isambert]

> Philip Taylor wrote:
> 
> > No no !  The OED says "< French m'aidez or m'aider ‘help me!’".
> > "French", in OED-speak, is Modern French; "OF" is how it denotes
> > Old French.
> 
> Well, I might be wrong.  The 2001 revision lists the following
> French-related languages :
> 
> > French
> > 
> > Walloon
> > Picard
> > Norman
> > Canadian French
> > Law French
> > 
> > Occitan
> > Franco-Provençal

‘Norman’ is probably ‘Anglo-Norman’, the French dialect imported by Billy the
Conqueror after he cleared the customs at Hastings in 1066. So that’s not
really young.

> The 1989 entry read :
> 
> > Also Mayday, mayday. [Phonetic repr. of F. m'aider imper. inf.
> > ‘help me!’, or shortening of venez m'aider.]
> 
> My 1933 printed edition (13 vol) has no entry but the gloss
> at the front gives "OF, OFr" for "Old French", even in the
> supplement.
> 
> Surely it is not possible that in the current (2001) edition, the
> distinction between Old French and French has been lost in
> the etymologies ?

That would be quite surprising. But anyway since the first attestation,
(according to the OED online) is 1923, there is little chance that ‘mayday’ is
centuries old, even though written speech always lags behind spoken speech (if
you’ll allow me so bold a pleonasm). So perhaps it’s simply ‘(venez) m’aider’.
Another possibility is that it was created in English as an imitation of
French, but not directly borrowed from French. We do that in French (all
languages do that): we have words like ‘tennisman’, which imitate English
words like ‘barman’, even though ‘tennisman’ does not exist in English (and
‘man’ isn’t even a French morpheme except in those words which imitate
English).

... Ah, but that’s probably that, according to Wikipedia:

The Mayday procedure word originated in 1923 by Frederick Stanley Mockford
(1897–1962). A senior radio officer at Croydon Airport in London, Mockford
was asked to think of a word that would indicate distress and would easily 
be
understood by all pilots and ground staff in an emergency. Since much of the
traffic at the time was between Croydon and Le Bourget Airport in Paris, he
proposed the word ‘Mayday’ from the French ‘m'aider’ (‘venez m'aider’ 
meaning
‘come help me’).

So you could say ‘mayday’ was borrowed from pseudo-French.

(Sorry for the off-topic-ness of all that.)

Best,
Paul



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] M'aidez, SVP : ** WARNING ** Version of PDF file (1.6) is newer than version limit specification.

[Paul Isambert]

Philip Taylor  a écrit:
> "M'aidez" v. "Aidez-moi" v. "Mayday" :  the OED has this to say --
> 
> > Etymology:  < French m'aidez or m'aider ‘help me!’ (the latter being
> > either the imperative infinitive or short for venez m'aider ‘come and
> > help me!’; < me , first person direct object pronoun + aider : see
> > aid v.).
> 
> as a result of which many Britons (myself included, obviously) have
> come to believe that "m'aidez" is correct in modern French (the OED,
> on which reliance can usually be placed, does not suggest otherwise).

The OED is right: both “m’aidez” (with the pronoun before the verb)
and “m’aider” (with an infinitive) were allowed in Old French. What
the OED does *not* say, I bet you, is that anything borrowed to
another language can be easily reused to speak that language...
especially when said language has been changing for centuries.

Best,
Paul



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] M'aidez, SVP : ** WARNING ** Version of PDF file (1.6) is newer than version limit specification.

[Paul Isambert]

I can help you with your French, but not the warning:

Philip Taylor  a écrit:
> As above, "m'aidez, SVP".

It’s “aidez-moi”, not “m’aidez”.

(That was intended as a friendly remark, of course, not one of those
nasty comments by self-titled “grammarians”, whose knowledge in
linguistics is as inexistent as my knowledge in volcanology.)

Best,
Paul



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] free (single) fonts from Linotype/Monotype merger announcement

[Paul Isambert]

Selon William Adams :

> This from the InDesign list:
>
> > Free download of fonts expires today, April 3.
> > Linotype/Monotype has put together a couple of font packs to download. See
> article and details at:
> > http://www.linotype.com/6987/linotypewirdmonotype.html
>
> NB - it's a single font from each family, but may be useful.

Thank you, William. The regular Gaillard can be useful (even though I've never
been very fond of that font). The bold italic Gill Sans, on the other hand...

Paul


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] The future of XeTeX

[Paul Isambert]

Philip TAYLOR  a écrit:
> 
> 
> Paul Isambert wrote:
> 
> > Ulrike Fischer  a écrit:
> 
> >> Sorry, but can you imagine that a typesetting engine can thrive
> >> which must say on its webpage "I'm a wonderful tex engine based on
> >> unicode but if you want to use open type fonts you will have to
> >> write or adapt a lot of complicated code first".?
> >
> > Honestly, yes :)  That's what TeX is to me anyway: a wonderful system that 
> > requires a lot
> > of hard work.
> 
> Yes, hard work at the macro/list-processing/expansion/execution level;
> but it (or rather, a 21-century derivative of "it", where "it" = "TeX")
> should not require hard work in order to interface properly with the
> font-handling aspects of the operating system on which it is installed.

The whole point of LuaTeX is to go a few levels deeper into TeX's
entrails; that includes fonts and nodes (``interfac[ing] properly with
the font-handling aspects of the operating system'' doesn't mean much:
loading a font is trivial; processing it in nodes is another matter
entirely).

>   XeTeX has demonstrated that this is not necessary, and that
> the engine itself can successfully be extended to handle those aspects
> (not, perhaps, in quite as elegant way as might be hoped, but infinitely
> better than not handling it at all).

If LuaTeX worked like XeTeX in that respect, it wouldn't be LuaTeX, it
would be XeTeX. Sorry to make such trivial statements, but what XeTeX
has demonstrated holds for XeTeX only.

> Now, it is perfectly reasonable to argue that LuaTeX has a different
> philosophy to XeTeX, and that there are things that can and should be
> done in Lua rather than in the core binary : few if any would differ
> with that.  But surely it is not unreasonable to ask the LuaTeX authors
> and maintainers to provide the interface to the font system (whether in
> core binary or in Lua would be entirely at their discretion) and to
> make that interface format agnostic.

That's, again and again, luaotfload, with all its imperfections.

Best,
Paul



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] The future of XeTeX

[Paul Isambert]

Martin Schröder  a écrit:
> 
> 2012/8/8 Ulrike Fischer :
> > Two years ago I would have said this too. But now I doubt it.
> > Opentype fonts are much more complicated that some expandafters or
> > the latex output routine. Also - more importantly - I see none of
> > the needed discussion going on.
> 
> That discussion is not helped by discussing *LuaTeX* issues
> on a *XeTeX* mailing list.

Right. I apologize for my launching that discussion here.

> OTOH the upcoming EuroTeX conference will be an excellent
> place for that discussion.

I give power of attorney to whatever stubborn LuaTeX fanatics will be
there; and there'll be plenty, since EuroTeX is coupled with the ConTeXt
meeting :)

Paul



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] The future of XeTeX

[Paul Isambert]

Ulrike Fischer  a écrit:
> 
> Am Wed, 8 Aug 2012 09:52:25 +0200 schrieb Paul Isambert:
> 
> 
> >> I personally don't care much *how* e.g. open type fonts are handled.
> >> The "typesetting engine" can use an external library, lua-files, or
> >> some library included in the binary. I care only *if* the core
> >> engine itself, the part advertised on the webpage, can handle the
> >> fonts like a bare xetex can handle them. 
> >> 
> >> Sorry, but can you imagine that a typesetting engine can thrive
> >> which must say on its webpage "I'm a wonderful tex engine based on
> >> unicode but if you want to use open type fonts you will have to
> >> write or adapt a lot of complicated code first".?
> > 
> > Honestly, yes :)
> > That's what TeX is to me anyway: a wonderful system that requires a lot
> > of hard work.
> > 
> > On http://www.luatex.org/roadmap.html, you can read:
> > 
> > There are two solutions for handling fonts: using the internal
> > functions that do what TeX has always done, or write a Lua function
> > that does a different job. As there are multiple solutions possible
> > and as we expect macro packages to have their own ways of dealing
> > with fonts, there is not one solution for dealing with fonts anyway.
> > Also, TeXies have always wanted full control over matters, and this
> > is provided by the Lua solution.
> 
> But allowing packages or formats to write and use their own code for
> open type fonts doesn't mean that the "luatex project" can ignore
> open type fonts completly. The fact that latex users can write
> beautiful and powerful packages e.g. for tabulars don't mean that
> the latex kernel don't have to provide code for tabulars.
> 
> I don't ask that a font loader should be included in the binary. A
> lua package which you can use in the font callback is fine. It is
> also okay if you need to adapt a configuration file before use e.g.
> to get it working with your texsystem or your os. The main point is
> that a working, default open type font loader should exist at all.

I think we simply disagree on the status of luaotfload. I see it as that
default fontloader you're talking about; non-ConTeXt users aren't
neglected (which was my starting point), thanks to it, although it
doesn't mean something better shouldn't be conceived by format authors.
As I understand you, it's not enough and it's imperfect anyway, so you
see the development of LuaTeX as terribly lacking in that respect.

I don't expect we'll agree on the subject, but at least I hope I got you
right.

> > In a few years, TeX users will have sprouted new wizards that'll deal
> > with fonts like the current wizards play with \output and \expandafter.
> 
> Two years ago I would have said this too. But now I doubt it.
> Opentype fonts are much more complicated that some expandafters or
> the latex output routine.

I'm not so sure. At least my personal experience tells me otherwise:
while OpenType was no pleasure cruise, it certainly wasn't as strange an
adventure as TeX.

>   Also - more importantly - I see none of
> the needed discussion going on. 

Until Khaled's recent announcement that he wouldn't continue luaotfload,
there was perhaps little need for most non-ConTeXt users; everybody was
more or less happy with the status quo; hopefully now people will act. I
haven't used luaotfload in months because I've developed my own
fontloader, and I know I'm not the only one in that position; sooner or
later something will emerge. All in all, we're not in a situation so
different to that where XeTeX is now, which spurred this discussion.

Perhaps I'm overly optimistic; yet I trust the community of TeXies,
which advances slowly yet decidedly.

Best,
Paul



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] The future of XeTeX

[Paul Isambert]

Ulrike Fischer  a écrit:
> 
> Am Tue, 7 Aug 2012 08:51:41 +0200 schrieb Paul Isambert:
> 
>  
> >>>> But there are also political issues: LuaTeX is developed by a
> >>>> team focusing on ConTeXt. LaTeX users will always be neglected,
> >>>> at least that is the feeling I have (Taco is very kind and
> >>>> helpful but he is paid for a specific task, and LaTeX is not
> >>>> part of it).
>   
> >>> I thought somebody would answer to that but nobody did, so (sorry to add
> >>> to this already too long thread, all the more as I won't even mention
> >>> XeTeX):
>   
> >>> Two members of the ``core'' LuaTeX team (Taco and Hans) are indeed two
> >>> main ConTeXt developers (and even original author, in Hans's case), but
> >>> I don't think you can say LuaTeX development focuses on ConTeXt (plus
> >>> Hartmut, the third member, is a LaTeX user, as far as I know). I'd
> >>> rather say that at most LuaTeX development may be driven by the needs
> >>> of ConTeXt developers, but that doesn't mean it benefits only to ConTeXt;
> >>> also, given ConTeXt's high standards, I think it's only for the best.
> >>> And the specific task Taco is paid for does not include LaTeX, but it
> >>> does not include ConTeXt either.
> >> 
> >> Well if you look only at the actual binary then yes your are right:
> >> it is not focused on context. But the handling of fonts is a core
> >> feature of a typesetting system. No user of a typesetting system
> >> would consider it to be complete if it can't handle standard fonts.
> >> So even if in luatex the font loader (including all the code needed
> >> to generate caches) is in external lua-files, it should nevertheless
> >> be considered to be part of "the luatex binary". It shouldn't
> >> delegate font handling to the formats.  
> 
> > I understand you're concerned about future font support in LuaTeX, but
> > technically the engine is little more than an extendable PDFTeX. 
> 
> I know this. But you are again looking only at the binary itself, at
> the "engine" in the narrow sense. I'm looking at the "typesetting
> project luatex". 
> 
> > Fonts follow that philosophy: TFM (with mapping to T1) fonts are
> > supported as in PDFTeX, other formats must be loaded and
> > processed by hand. Whether it's a good idea or not in that case I
> > don't know, but it is definitely consistent. (Actually I do think
> > it's a good idea, but I accept my opinion might be marginal.)
> 
> I personally don't care much *how* e.g. open type fonts are handled.
> The "typesetting engine" can use an external library, lua-files, or
> some library included in the binary. I care only *if* the core
> engine itself, the part advertised on the webpage, can handle the
> fonts like a bare xetex can handle them. 
> 
> Sorry, but can you imagine that a typesetting engine can thrive
> which must say on its webpage "I'm a wonderful tex engine based on
> unicode but if you want to use open type fonts you will have to
> write or adapt a lot of complicated code first".?

Honestly, yes :)
That's what TeX is to me anyway: a wonderful system that requires a lot
of hard work.

On http://www.luatex.org/roadmap.html, you can read:

There are two solutions for handling fonts: using the internal
functions that do what TeX has always done, or write a Lua function
that does a different job. As there are multiple solutions possible
and as we expect macro packages to have their own ways of dealing
with fonts, there is not one solution for dealing with fonts anyway.
Also, TeXies have always wanted full control over matters, and this
is provided by the Lua solution.

In a few years, TeX users will have sprouted new wizards that'll deal
with fonts like the current wizards play with \output and \expandafter.

> > Now, as I've already said, Hans has written a format-independent font
> > loader; somebody is only required to make the necessary adjustments to
> > (La)TeX, as Khaled did until recently. 
> 
> At first it should not be necessary "to make adjustments". A
> format-independant font loader should work like the extended
> \font-command of xetex "out-of-the box".

To me the XeTeX syntax is rather the frosting on the cake; the important
point is that a font be loaded and processed.

>  At second as some people
> complained here in the discussion the font loader doesn&

Re: [XeTeX] The future of XeTeX

[Paul Isambert]

Ulrike Fischer  a écrit:
> 
> Am Sat, 4 Aug 2012 09:38:44 +0200 schrieb Paul Isambert:
> 
> 
> >> But there are also political issues: LuaTeX is developed by a
> >> team focusing on ConTeXt. LaTeX users will always be neglected,
> >> at least that is the feeling I have (Taco is very kind and
> >> helpful but he is paid for a specific task, and LaTeX is not
> >> part of it).
>  
> > I thought somebody would answer to that but nobody did, so (sorry to add
> > to this already too long thread, all the more as I won't even mention
> > XeTeX):
>  
> > Two members of the ``core'' LuaTeX team (Taco and Hans) are indeed two
> > main ConTeXt developers (and even original author, in Hans's case), but
> > I don't think you can say LuaTeX development focuses on ConTeXt (plus
> > Hartmut, the third member, is a LaTeX user, as far as I know). I'd
> > rather say that at most LuaTeX development may be driven by the needs
> > of ConTeXt developers, but that doesn't mean it benefits only to ConTeXt;
> > also, given ConTeXt's high standards, I think it's only for the best.
> > And the specific task Taco is paid for does not include LaTeX, but it
> > does not include ConTeXt either.
> 
> Well if you look only at the actual binary then yes your are right:
> it is not focused on context. But the handling of fonts is a core
> feature of a typesetting system. No user of a typesetting system
> would consider it to be complete if it can't handle standard fonts.
> So even if in luatex the font loader (including all the code needed
> to generate caches) is in external lua-files, it should nevertheless
> be considered to be part of "the luatex binary". It shouldn't
> delegate font handling to the formats.  

I understand you're concerned about future font support in LuaTeX, but
technically the engine is little more than an extendable PDFTeX. Fonts
follow that philosophy: TFM (with mapping to T1) fonts are supported
as in PDFTeX, other formats must be loaded and processed by hand. Whether
it's a good idea or not in that case I don't know, but it is definitely
consistent. (Actually I do think it's a good idea, but I accept my
opinion might be marginal.)

Now, as I've already said, Hans has written a format-independent font
loader; somebody is only required to make the necessary adjustments to
(La)TeX, as Khaled did until recently. My main point was not whether
LuaTeX was well-designed, but whether (La)TeX users could be said to be
neglected, which I still think isn't the case.

Best,
Paul



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] The future of XeTeX

[Paul Isambert]

Yannis Haralambous  a écrit:
> But there are also political issues: LuaTeX is developed by a team focusing 
> on ConTeXt.
> LaTeX users will always be neglected, at least that is the feeling I have 
> (Taco is very kind
> and helpful but he is paid for a specific task, and LaTeX is not part of it).

I thought somebody would answer to that but nobody did, so (sorry to add
to this already too long thread, all the more as I won't even mention
XeTeX):

Two members of the ``core'' LuaTeX team (Taco and Hans) are indeed two
main ConTeXt developers (and even original author, in Hans's case), but
I don't think you can say LuaTeX development focuses on ConTeXt (plus
Hartmut, the third member, is a LaTeX user, as far as I know). I'd
rather say that at most LuaTeX development may be driven by the needs
of ConTeXt developers, but that doesn't mean it benefits only to ConTeXt;
also, given ConTeXt's high standards, I think it's only for the best.
And the specific task Taco is paid for does not include LaTeX, but it
does not include ConTeXt either.

For LaTeX users to be neglected, there should be some particular LaTeX
needs that the LuaTeX team does not pay attention to; but I can't see
such a need.

I use neither ConTeXt nor LaTeX, but plain TeX, and I've always found
Taco willing to implement features when they were sensible; on the other
hand, I've never felt this or that (lack of) feature was due to LuaTeX
being written for ConTeXt, and I think that's because it isn't. In other
words, I've never felt neglected.

Now, if you have in mind not so much the development of LuaTeX itself
but of packages written for LuaTeX, then indeed non-ConTeXt users may
be lagging behind. But that's not due to the LuaTeX team; Hans is working
hard to adapt ConTeXt to LuaTeX; we should work hard to do the same in
other formats (and actually some people do). Also remember that Hans
wrote a generic fontloader so it could be adapted to all formats (in
the guise of luaotfload, notwithstanding the current problematic state
of affairs). So, in general, if non-ConTeXt users should feel neglected,
that's only because of a lack of development of code based on LuaTeX;
but that's not an argument against the engine itself.

Best,
Paul



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] How to add ExtGState to xdvipdfmx?

[Paul Isambert]

Zdenek Wagner  a écrit:
> 
> Hello,
> 
> I have an ExtGState defined as:
> 
>   \special{pdf: object @opoff << /Type /ExtGState /op false /OP false /OPM 0 
> >>}
>   \special{pdf: object @opon << /Type /ExtGState /op true /OP true /OPM 1 >>}
>   \special{pdf: object @extgs << /GSko @opoff /GSop @opon >>}
>   \special{pdf: object @ExtGS << /ExtGState @extgs >>}
> 
> These commands go to the PDF exactly as in a pdftex file which works.
> Now I need to define @ExtGS in /Resources at each page where I use
> /GSko or /GSop. I tried several ways but all seem to be wrong, it was
> not written to the PDF file. Can someone write me how to do it?

According to the doc you get with "texdoc dvipdfmx" (also available
here: http://tug.org/TUGboat/tb30-1/tb94cho.pdf), the operation is:

  \special{pdf:put @resources << /ExtGState @extgstate >>}

Best,
Paul



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Bad handling of lookup subtables.

[Paul Isambert]

Jonathan Kew  a écrit:
> 
> This sounds like http://bugs.icu-project.org/trac/ticket/7753

Indeed; I didn't know about the tracker. Sorry for the noise!

Best,
Paul



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

[XeTeX] Bad handling of lookup subtables.

[Paul Isambert]

Hello all,

I use XeTeX to do some testing on fonts. If I'm not mistaken, given a
lookup with subtables, the latter are tried one after the other until
one of them identifies a proper input and is applied. In other words,
only one subtable should be applied for a given lookup.

However, it seems to me that XeTeX applies all subtables; in most cases,
this is harmless, since only one of them finds a proper input anyway.
But in some cases, a subtable may be designed precisely to prevent a
subsequent subtable from matching in some contexts.

For instance, this is how the "ss02" feature in Minion Pro works (Minion
Pro is distributed with Acrobat, which is why I use it as an example).
This feature replaces some letter, e.g. "e", by variants ("e.end") in
some contexts (at the end of a word). To do so, a first subtable matches
"e + X", where "X" is another letter, and does nothing; a second subtable
matches "e" anywhere and does the replacement. The net effect is that
"e" is replaced with "e.end" only when not followed by another letter,
since the first subtable prevents the second from matching in unwanted
contexts.

However, since XeTeX applies all subtables, the replacement is always
done. I've also tested that with a stupid handmade substitution turning
"a" to "b" (first subtable) and "b" to "c" (second subtable), just to
make sure XeTeX wasn't confused by dummy subtables (i.e. performing no
change) and/or contextual substitutions; the test was positive as I
ended up with "a" turned to "c" instead of "b".

As far as I'm concerned, this is a pretty serious bug; but perhaps I've
missed something (including, who knows, that this bug has already been
spotted)?

Best,
Paul



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Preventing a line break at a given set of characters

[Paul Isambert]

Shiva Shankar  a écrit:
> 
> Hi,
> 
> Is it possible to prevent the linebreak at a given set of characters?
> for example TeX will never break a line at fullstop(.) I mean
> fullstop alone never goto next line (unless there is a space behind
> it). Similarly for comma(,), semicolon(;) etc.

You can always set \lccode to 0 for the characters you want to be
unbreakable, but that will mess with word recognition globally, so you
won't have hyphenation where you don't want it, but you won't have it
either in many places where expected. A solution might be to add a
glue -- preceded by an infinite penalty -- after the character to mark
the legitimate end of a word; you might be able to do that automatically
with interchartoks; that won't solve problem with \right/lefthyphenmin,
though. See e.g.:

% Normal hyphenation.
\showhyphens{absolutely}

% Bad solution.
\lccode`\t=0
\showhyphens{absolutely}

% Better solution.
\XeTeXinterchartokenstate=1
\XeTeXcharclass`\t=10
\XeTeXinterchartoks 10 0 = {\penalty1\hskip0pt}
\showhyphens{absolutely}

I'm not sure this is sound.

Of course, you can also declare exceptions with \hyphenation, provided
you don't have too many of them.

Best,
Paul



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] XeTeX, XeTeXpicfile, and counter-intuitive behaviour

[Paul Isambert]

Le 01/12/2011 13:13, Philip TAYLOR a écrit :

P.S. But what about the fact that the \vfill \eject
is ignored if no text precedes the \XeTeXpicfile ?


It seems to be a particular case of the situation where a \special is 
alone on its page. I don't know what TeX is supposed to do in such 
situation, and haven't time to investigate.


Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] XeTeX, XeTeXpicfile, and counter-intuitive behaviour

[Paul Isambert]

Le 01/12/2011 12:49, Philip TAYLOR a écrit :

Problem 2 (completely intractable) : XeTeX claims to be unable to find
"TAR-2.pdf", despite the fact that it is in the same directory as
"IMG_2206.JPG" and that both filenames were inserted by initiating
a file rename, copying the current name, and then cancelling the
rename operation.  Both files open normally in their associated
programs.

! Unable to load picture or PDF file 'Resources/Images/TAR-2.pdf'.

   \relax
l.128 ...rces/Images/TAR-2.pdf width \hsize \relax



Use \XeTeXpdffile ...


H E L P !!!


... and keep cool :)

Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] [tex-live] Ftuture state of XeTeX in TeXLive

[Paul Isambert]

Le 30/10/2011 17:20, Petr Tomasek a écrit :

On Sun, Oct 30, 2011 at 04:29:18PM +0100, Paul Isambert wrote:

Le 30/10/2011 13:20, George N. White III a écrit :

On Sun, Oct 30, 2011 at 7:42 AM, Khaled Hosny

wrote:

Writing an OpenType layout engine is not a simple task, and you can
judge from the many years it toke FOSS community to have a really good
one, HarfBuzz (the name luaotfload is misleading, font loading is about
the easiest part of luaotfload, OpenType implementation is really what
matters.) If it were for me, I'd plug HarfBuzz into luatex proper and
call it a day, but this does not align well with the "design" principles
of luatex so it is unlikely to happen.

If plugging harfbuzz into luatex does not require a huge effort, it could
serve as bridge from xetex to luatex while a more principled design
is being created. Principles are nice, and have benefits over the long
haul, but in cases where the design is evolving it really helps to get
an implementation into the hands of users and let them point out the
areas where work is needed.

As far as I can see, the principles behind LuaTeX are pretty clear; it
offers tools, not solutions. Sometimes that makes it apparently slow-witted,
like TeX itself, because it refuses to implement solutions that seem
successful elsewhere. But one shouldn't forget that (Lua)TeX is an
extremely sophisticated typographic system, and that flexibility is an
integral part of it. Using HarfBuzz would probably offer a simple solution,
but you'd lose what makes LuaTeX so worthwhile.

Best,
Paul

What is so "worthwile" on cripling one scripting language with
another one?


I don't understand your (I suppose) rhetorical question. Do you mean 
crippling TeX with Lua? If that's how you see LuaTeX, I think there 
isn't much we're going to agree on.


Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] [tex-live] Ftuture state of XeTeX in TeXLive

[Paul Isambert]

Le 30/10/2011 13:20, George N. White III a écrit :
 On Sun, Oct 30, 2011 at 7:42 AM, Khaled Hosny  

wrote:

> Writing an OpenType layout engine is not a simple task, and you can
> judge from the many years it toke FOSS community to have a really good
> one, HarfBuzz (the name luaotfload is misleading, font loading is about
> the easiest part of luaotfload, OpenType implementation is really what
> matters.) If it were for me, I'd plug HarfBuzz into luatex proper and
> call it a day, but this does not align well with the "design" principles
> of luatex so it is unlikely to happen.

 If plugging harfbuzz into luatex does not require a huge effort, it could
 serve as bridge from xetex to luatex while a more principled design
 is being created. Principles are nice, and have benefits over the long
 haul, but in cases where the design is evolving it really helps to get
 an implementation into the hands of users and let them point out the
 areas where work is needed.


As far as I can see, the principles behind LuaTeX are pretty clear; it
offers tools, not solutions. Sometimes that makes it apparently slow-witted,
like TeX itself, because it refuses to implement solutions that seem
successful elsewhere. But one shouldn't forget that (Lua)TeX is an
extremely sophisticated typographic system, and that flexibility is an
integral part of it. Using HarfBuzz would probably offer a simple solution,
but you'd lose what makes LuaTeX so worthwhile.

Best,
Paul



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] [tex-live] Ftuture state of XeTeX in TeXLive

[Paul Isambert]

Le 30/10/2011 06:25, Vafa Khalighi a écrit :

 XeTeX font support is heaps better and stable than what luaotfload
 package offers and I guess that is why many users still like using
 xetex instead luatex. I personally believe that it is a bad practice
 that luaotfload just copies ConTeXt code, it should not be deeply
 dependent on ConTeXt because Hans may want to try experimenting with
 some features today and next day he gets rid of them just like the
 recent updates of luaotfload that Khaled talked about it. I think,
 this is awful! What should users who used those features (and need it
 heavily in their daily typesetting tasks, do?). They wake up one day
 and suddenly see that yes, luaotfload does not provide the features
 they need. luaotfload needs to be written from scratch independent of
 any ConTeXt code.


An independent fontloader could very well be unstable too. But anyway I
suppose this will happen some day; relying on Hans's code is the only
solution for the moment, because nobody has written a public alternative
(and writing such an alternative is no simple task), but I don't suppose
it will remain so.

As far as I'm concerned, I don't use luaotfload but my own fontloader.
It is not public for the moment because it doesn't do much more than
what I need to do. But I have good hope that somebody will some day come
with a full solution; or perhaps different people will write partial
solutions (someone could write something for latin typography, somebody
else could devise an arabic fontloader, and so on and so forth). The
problem is, it's easier to blame luaotfload for its uncertain status
than to sit down and write a replacement; so please let's not forget
that without luaotfload LuaTeX wouldn't be different from PDFTeX as far
as fonts are concerned.

Best,
Paul



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Odd hyphenations

[Paul Isambert]

Le 30/09/2011 16:26, NEAL DELMONICO a écrit :

Greetings All,

I am having some problems with hyphenation in English and wonder if I 
am missing something important in my header file.  The hyphenation 
program seems to be misfiring since it gives the following 
hyphenations: n-ear, s-mall, b-lissful, s-miling, y-our, and many more 
like this.  I have been going though and adding those words to my 
\hyphenation{} command and that usually fixes them.  But, as I go 
through the book, I find that I find a bad hyphenation every few 
pages.  There are a lot of Indic words in the text and hyphenation 
will often mess them up.  That is understandable, but the wrong 
hyphenation of these English words is puzzling.  Any suggestions?


Before \begin{document}, \lefhyphenmin (the minimal number of characters 
before a break, 2 by default for English) is 2, and 1 after 
\begin{document}, unless you comment the line 
"\setotherlanguage{sanskrit}". So something is wrong with polyglossia, 
from which I suppose the command comes from.


Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] analogues of \pdfobj?

[Paul Isambert]

Le 30/08/2011 12:19, Oleg Parashchenko a écrit :

Hello again,

On Fri, 26 Aug 2011 12:32:14 +0200
Heiko Oberdiek
wrote:

...

* \pdfobj useobjnum/pdfobj: Objects can be constructed by
 \special{pdf:object ...}
 \special{pdf:put ...}
 \special{pdf:close ...}
 \special{pdf:stream ...} (dvipdfmx)
 \special{pdf:fstream ...} (dvipdfmx)

My idea was to implement one-pass "part K of N" functionality for
multipage tables. With pdftex it is easy, at least the test code works:

%%%
\pdfobj reserveobjnum {}
\mathchardef\num\pdflastobj

\edef\ppp{\noexpand\pdfliteral{BT [\the\pdflastobj\space 0 R]TJ ET}}
\def\para{Counter++. The final value is \ppp\par}

\para
\para

\immediate\pdfobj useobjnum\num {(test)}
%%%

Thanks to your suggestions, I thought that I could make a similar trick
with DVIPDFMx, but so far no solution is found, despite I tried several
different approaches. For further assistance, a letter ot the DVIPDFMx
mailing list is sent.


I'm not sure I understand clearly what you want to do, but I'll remark 
that the Navigator package offers a unified interface for PDF objects 
under current engines.


Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Loading fonts from a common server or http URL

[Paul Isambert]

Le 22/06/2011 09:28, Philip TAYLOR (Webmaster, Ret'd) a écrit :



Venkatesan. S.K. (TNQ) wrote:


It is more a *fontspec* question and may be it has wider scope...
Is it possible to load fonts from http URLs?
i.e., can I do this:
\fontspec{http://www.ctan.org/public/fonts/STIXGeneral.otf}.

[...]
Unfortunately I am not aware of any implementation of [Xe]TeX
that supports this; probably the most likely candidate would
be LuaTeX (Taco cc'd) but I do not think that even LuaTeX
yet supports this concept.


I don't know much about that subject, but LuaTeX includes the LuaSocket 
library which, if I'm not mistaken, does exactly that: access remote files.


Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] [Off-topic] Persian versus Farsi

[Paul Isambert]

Le 11/06/2011 16:23, Vafa Khalighi a écrit :



The problem is that some people think they are the center of the
universe and the rest

have only one purpose: to harm them!


Can you name one single movie of Hollywood which was not offensive to 
Persians?


Err, Terminator?

or Let me ask my question the other way, Can you name a movie that has 
been made about any of Persian heros? A movie about Cyrus the great? a 
movie about Dariush the great? a movie about Ariobarzanes? A movie 
about Surena? and the list goes on.



There are many unsung `heroes' in Hollywood.



Let me say that some people here in Greece

did not like the movie either because Alexander was portraited as
a homosexual. 




Well, history says he was.


Historians debate, at best. Homesexuality might not even be a 
well-defined concept in that respect.



Further homosexuality originated from Greece.


That is absolutely stupid. Homosexuality (if one can conflate what this 
term denotes now and a reality more than 2000-year old) existed in 
ancient Greece, but elsewhere too.
How do you expect to be respected and well-considered if you go on with 
such prejudice yourself?


No one can deny that Alexander burnt Perspolis and killed many 
innocent Persian, so much for an angel.


Conquerors are seldom angels, no matter whether we're talking about 
Alexander, Napoleon -- or Darius, for that matter. That some people find 
them fascinating nonetheless is a frightening trait of the human species.




Of course
you could say the similar things about the "300" movie/comic book,
but you and many/some

of my compatriots should realize that artists should be freeto
express themselves.



Artists can be free to do whatever they want as long as they do not 
try to make bogus!


Artist are free to express themselves; /we/ shouldn't mistake them for 
historians.


Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Fonts : test

[Paul Isambert]

Le 08/06/2011 13:14, Jean-Louis Cordonnier a écrit :

In order to choose the right fontface for my document, I want to make a
test.
My purpose is to get a document like this :

Font 1 :
abcde...
Font 2 :
abcde...
Font 3 :
abcde

Is it possible to do this in a short way ?


If I understand you correctly, this will do:

%%%
\def\testtext{Whatever text you want to use...}
\def\testfont#1{%
  \font\temp="#1"
  \temp
  \vskip\baselineskip#1:\par
  \testtext
  }
%%%

Then: \testfont{Chaparral Pro} \testfont{cmr10}...

Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] xetex

[Paul Isambert]

If I'm not mistaken, XeTeX = X + eTeX, with X for Mac OS X (XeTeX's 
original intended platform), and eTeX being the well-known Extended TeX 
(since XeTeX takes over eTeX). As for TeX...


Of course, the symmetry also emphasizes bidirectional writing, as once 
TeX--XeT did.


Best,
Paul


Le 10/04/2011 00:37, marc rousseau a écrit :

Hi
  I'd like to know what does the letter in xetex stand for ?
thx




--
Subscriptions, Archive, and List information, etc.:
   http://tug.org/mailman/listinfo/xetex


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Character Variants

[Paul Isambert]

Le 27/03/2011 22:07, msk...@ansuz.sooke.bc.ca a écrit :

On Sun, 27 Mar 2011, Peter Dyballa wrote:

U+8FBB exists in this and quite a few other fonts, but which font has U+E0100?
(And since this character is outside the BMP, the Basic Multilingual Pane, it
won't be some usual font.)

U+E0100 is not a graphic character in itself, but a "variation selector"
specifying an alternate form for the preceding character; it behaves a
little bit like a combining character.  What I don't know is how that's
supposed to be implemented - whether it is done by the font with glyph
substitution, or by some other mechanism that requires support from the
rendering engine.


Both, actually. The font by itself does nothing, it simply indicates 
what the rendering engine should do. I suppose (because it's seems the 
simplest way here) that this is implemented as a ligature.


Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] xeindex bug. index entry mangles processing of section and chapter environments.

[Paul Isambert]

Le 15/02/2011 19:03, Michael Joyner a écrit :



On Mon, Feb 14, 2011 at 6:25 PM, Paul Isambert <mailto:zappathus...@free.fr>> wrote:



Nice, you've just discovered a bug in XeSearch. 

Bleck. I don't consider it nice. Why am I the one always finding these 
bugs that don't afflict other people? :(


Perhaps because XeSearch and XeIndex aren't widely used. (Not even by 
me, otherwise those bugs would have been fixed long ago. By the way, I 
don't use them not because I think they're bad, but because I've become 
a LuaTeX user in the meanwhile. I /thought/ they were good :) )



Basically, it builds an horizontal box; \section inserts a
vertical command (\vskip) at the end of its argument; but TeX
doesn't like vertical commands in horizontal boxes, hence the
complaining. This happens only when searching for phrases, not
simple words, because such things as \vskip are boundaries to
XeSearch, so it normally closes the box, but boundaries are
ignored when searching for phrases.

Just ran into a case where it occurs for a single word. Please see 
example document below.


Actually it's the same thing. XeSearch doesn't trim space around words, 
hence


\IndexList{xeindexList}
{
Virus
}

amounts to searching for " Virus " which, technically, is a phrase, not 
a word. Just remove spurious space:


\IndexList{xeindexList}
{%
Virus%
}




Right now I can only recommend stopping the search before the
section title and starting it again after. I know it's far from
satisfying, but I have to think about a better solution.

Haven't quite figured out how to do that yet without changing lots of 
stuff not directly related to the indexing so I was trying to index 
just "words" and not "phrases". :)


XeIndex has a \NoIndex command, but I've just tested it, it won't work 
in \section. So you can surround the section title with XeaSearch's 
\StopSearching/\StartSearching, unless you have other operartions going 
on with XeSearch.


Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] OT features

[Paul Isambert]

Le 15/02/2011 11:14, Georg A. Duffner a écrit :

Am 2011-02-15 04:38, schrieb David J. Perry:

I had the exact same problem last weekend. I constructed an OT feature
to replace a long s with a regular s if followed by a comma, period,
space, etc. The longs-space combination did not work. I am not a
low-level TeX programming kind of guy, but I had learned a bit somewhere
about TeX's "glue" and I wondered if the OT parser did not see the space
character. Thanks to Khaled for confirming this.

David


- Original Message - From: "Khaled Hosny" 


To: "Unicode-based TeX for Mac OS X and other platforms" 
Sent: Monday, February 14, 2011 6:35 PM
Subject: Re: [XeTeX] OT features



On Mon, Feb 14, 2011 at 10:24:14PM +0100, Georg A. Duffner wrote:

For my font project (see www.georgduffner.at/ebgaramond) i have been
playing around with some opentype features. It seems, that
contextual features involving the character "space" don’t work as
expected.


AFAIK, XeTeX processes each word in isolation, so space never part of
context (also in TeX space is not a character/glyph but a kind of a
property named glue, so it does not get handled by OT layout).

Generally speaking, using space in context is fragile and not 
guaranteed

to work everywhere.


I wanted to implement a feature for latin texts that
replaces "u" at the beginning of a word by a letter that looks like
"v". The rule looks like this:


'init' feature should be more suitable here, but almost all OT engine
supports it for few selected scripts (Arabic mainly). With 'init' it is
the responsibility of the engine to detect word beginning.



Thanks Khaled,

I already feared such implication being the culprit. In this case, the 
solution was simple since it’s easy to reverse the lookup: replace 
every "u" by a "v"-like glyph and then make a contextual rule that 
changes them to a "u"-like one after a letter. But I don’t think I’m 
gonna keep this as default for latin but rather put it in a stylistic 
set.


I'm quite new to the internals of OT, but what I've seen implemented in 
similar cases looks more like this: keep "u" as is, and make a 
contextual rule on it with two lookups: the first is triggered whenever 
there's something before the "u", and does nothing; the second is 
triggered in any context and changes "u" to "v". If the first applies, 
the second doesn't. That's the way word-final variants are implemented 
in Minion, except the context of the first lookup is not all glyphs, but 
almost all glyphs, excluding for instance punctuation marks. Thinking 
about it, this should be the case for you too: the first lookup 
shouldn't be triggered by a left parenthesis.


(Sorry if I don't have the terminology right, I've been investigated 
fonts for some weeks only.)


Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] xeindex bug. index entry mangles processing of section and chapter environments.

[Paul Isambert]

Le 15/02/2011 00:00, Michael Joyner a écrit :

Good afternoon all,

I having gotten much further along with the xeindexing, but have run 
into a new problem.


I have created and inserted below a test document showing an 
un-numbered section getting mangled.


What I really find strange is that the text being mangled is a 
substring of the text being searched for indexing.


I am searching via xeindex for 'Clinical Trial Research', but the 
fragment "\section*{Resverlogix Activates First Site for ASSURE 1 
Clinical Trial}" is ending up with a missing '}' after the word 'Trial'.


One can also change "\chapter{Clinical Trials}" to "\chapter{Clinical 
Trial}" and have the error occur there instead.


Nice, you've just discovered a bug in XeSearch. Basically, it builds an 
horizontal box; \section inserts a vertical command (\vskip) at the end 
of its argument; but TeX doesn't like vertical commands in horizontal 
boxes, hence the complaining. This happens only when searching for 
phrases, not simple words, because such things as \vskip are boundaries 
to XeSearch, so it normally closes the box, but boundaries are ignored 
when searching for phrases.


Right now I can only recommend stopping the search before the section 
title and starting it again after. I know it's far from satisfying, but 
I have to think about a better solution.


(Fortunately, after xeindex, I stop writing packages I couldn't use.)

Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Running out of memory in XeSearch while trying to XeIndex on largish latex files.

[Paul Isambert]

Le 10/02/2011 15:58, Michael Joyner a écrit :



On Thu, Feb 10, 2011 at 8:21 AM, Paul Isambert <mailto:zappathus...@free.fr>> wrote:


Le 10/02/2011 04:39, Ross Moore a écrit :

Hi Michael, and Heiko,

On 10/02/2011, at 1:49 PM, Michael Joyner wrote:


On Wed, Feb 9, 2011 at 9:30 PM, Ross
Mooremailto:ross.mo...@mq.edu.au>>
 wrote:


See how large you can set the  "save size" parameter.
Multiply by 10, or 100, or 1000... .

I'd say you are exploring to the boundaries of what XeTeX
is capable of doing.


save size won't go over 80,000 :(

OK.

But we don't need it now.
Here's the cause of the problem.

The package source  xesearch.sty   has a technical problem.
The macros  \xs@String  and  \xs@Stack  are used as variables,
repeatedly changing their expansions. However, sometimes the code
uses \edef\xs@String{...} but mostly it uses \xdef\xs@String{...}.

This mixture of local/global scope is what causes the loss of
string space, because an \edef instance requires the previous
\xdef
instance to be retained, not discarded. Then comes another \xdef
which may release the previous \edef's memory, but not that of the
 \xdef  prior to the \edef .  Hence memory usage grows.

By making all instances become global, I now get your document to
finish, along with the Index page.

Here's the memory usage:

Here is how much of TeX's memory you used:
 26092 strings out of 494542
 451878 string characters out of 3157455
 480737 words of memory out of 300
 29083 multiletter control sequences out of
15000+20
 8574 words of font info for 51 fonts, out of
300 for 9000
 669 hyphenation exceptions out of 8191
 40i,7n,43p,1687b,9339s stack positions out of
5000i,500n,1p,20b,5s




Here's the patch needed to modify  xesearch.sty .



Does this look right?


This looks ok to me, except:


@@ -975,7 +975,7 @@
-  \def\xs@String{#2}%
+  \gdef\xs@String{#2}%



@@ -983,7 +983,7 @@
-  \def\xs@Stack{#2}%
+  \gdef\xs@Stack{#2}%


(I've turned \xdef into \gdef). Now, if your document works properly, 
I'll release the patch.

Thanks again,
Paul



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Running out of memory in XeSearch while trying to XeIndex on largish latex files.

[Paul Isambert]

Le 10/02/2011 04:39, Ross Moore a écrit :

Hi Michael, and Heiko,

On 10/02/2011, at 1:49 PM, Michael Joyner wrote:



On Wed, Feb 9, 2011 at 9:30 PM, Ross Moore  wrote:


See how large you can set the  "save size" parameter.
Multiply by 10, or 100, or 1000... .

I'd say you are exploring to the boundaries of what XeTeX
is capable of doing.


save size won't go over 80,000 :(

OK.

But we don't need it now.
Here's the cause of the problem.

The package source  xesearch.sty   has a technical problem.
The macros  \xs@String  and  \xs@Stack  are used as variables,
repeatedly changing their expansions. However, sometimes the code
uses \edef\xs@String{...} but mostly it uses \xdef\xs@String{...}.

This mixture of local/global scope is what causes the loss of
string space, because an \edef instance requires the previous \xdef
instance to be retained, not discarded. Then comes another \xdef
which may release the previous \edef's memory, but not that of the
  \xdef  prior to the \edef .  Hence memory usage grows.

By making all instances become global, I now get your document to
finish, along with the Index page.

Here's the memory usage:


Here is how much of TeX's memory you used:
  26092 strings out of 494542
  451878 string characters out of 3157455
  480737 words of memory out of 300
  29083 multiletter control sequences out of 15000+20
  8574 words of font info for 51 fonts, out of 300 for 9000
  669 hyphenation exceptions out of 8191
  40i,7n,43p,1687b,9339s stack positions out of 5000i,500n,1p,20b,5s




Here's the patch needed to modify  xesearch.sty .


[GlenMorangie:tex/xetex/xesearch] rossmoor% diff xesearch-*.sty
169c169
<  \edef\xs@String{\xs@unexpanded\expandafter{\xs@String} }%
---

 \xdef\xs@String{\xs@unexpanded\expandafter{\xs@String} }%

178c178
<\edef\xs@String{\xs@unexpanded\expandafter{\xs@String} }%
---

   \xdef\xs@String{\xs@unexpanded\expandafter{\xs@String} }%

687c687
<  \def\xs@Stack{}
---

\xdef\xs@Stack{}

692c692
<\def\xs@String{}%
---

   \xdef\xs@String{}%

696c696
<\def\xs@Stack{}%
---

   \xdef\xs@Stack{}%

911c911
<  \def\xs@Stack{}%
---

 \xdef\xs@Stack{}%

978c978
<\def\xs@String{#2}%
---

   \xdef\xs@String{#2}%

986c986
<\def\xs@Stack{#2}%
---

   \xdef\xs@Stack{#2}%


I'll leave it to the author to verify that these changes
do not affect the functionality of the package in any
detrimental way.
Or if not, to modify  xesearch.sty  differently, while
avoiding the mistake of mixing local and global definitions
of the save macro-name.


I'll be happy to include the patch if it works. I generally use 
local/global assignment with a purpose, but I might have been fussy (I 
remember XeSearch being one painful gestation). And I'll admit I'm 
under-educated re those memory stack things or whatever.
Anyway, many thanks Ross for taking the trouble to look into that 
spaghetti code and spotting the problem.


Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Running out of memory in XeSearch while trying to XeIndex on largish latex files.

[Paul Isambert]

Le 10/02/2011 02:55, Heiko Oberdiek a écrit :

On Wed, Feb 09, 2011 at 10:17:54PM +0100, Paul Isambert wrote:


Le 09/02/2011 20:52, Michael Joyner a écrit :

We are trying to use XeIndex/XeSearch on what we consider to be
some medium/small documents and are getting the following error:

! TeX capacity exceeded, sorry [save size=8].
\pdfstringdef ... \let \GenericError \@gobblefour
  \let
\GenericWarning \@gob...
l.5671
Here is how much of TeX's memory you used:
 26308 strings out of 494522
 458137 string characters out of 503842
 738532 words of memory out of 300
 29310 multiletter control sequences out of 15000+20
 9330 words of font info for 51 fonts, out of 300 for 9000
 670 hyphenation exceptions out of 8191
 40i,7n,43p,500b,80001s stack positions out of
5000i,500n,1p,20b,8s
Output written on 02944.pdf (79 pages).


I have tried increasing the 'save size' above 8, but it
doesn't seem to go any higher. :(

This occurs when the package is loaded, regardless as to whether
we specify words to index or not.

We tested with just XeSearch loading, and the same error occurred.

We would really appreciate any advice on this.

Without a minimal example, there isn't much I can do. But possible
loops are described on page 5 of the doc. Are you sure you're not in
such a case?

\documentclass{article}
\usepackage{xesearch}
\begin{document}
\tracingassigns=1
Hello World
\tracingassigns=0
\end{document}

The example shows that each word creates two command sequences,
example for "Hello":

   {changing \Hello@cs@xs@words=undefined}
   {into \Hello@cs@xs@words=\relax}
   {changing \hello@ncs@xs@words=undefined}
   {into \hello@ncs@xs@words=\relax}

I don't know the internals of xesearch.sty, but do you really need
the meaning \relax? Or it is just the usual side effect of TeX's
\csname?


The problem is I switched to LuaTeX not long after releasing XeSearch, 
so I haven't practised it much.
But I know I do such things generally to turn the control sequence into 
a switch:


\ifdefined\Hello@cs@xs@words
% Somehting related to "Hello" is on.
\else
% It's off.
\fi


In \xs@@F@Test you are using:

   \expandafter\ifx\csname\xs@String @cs@xs@words\endcsname\relax

Perhaps you can replace it by \ifcsname ...\endcsname?


Oh yes I can, and I don't know why I didn't use \ifcsname in the first 
place.


Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Running out of memory in XeSearch while trying to XeIndex on largish latex files.

[Paul Isambert]

Le 09/02/2011 20:52, Michael Joyner a écrit :

Good Afternoon,

Help! :)

We are trying to use XeIndex/XeSearch on what we consider to be some 
medium/small documents and are getting the following error:


! TeX capacity exceeded, sorry [save size=8].
\pdfstringdef ... \let \GenericError \@gobblefour
  \let
\GenericWarning \@gob...
l.5671
Here is how much of TeX's memory you used:
 26308 strings out of 494522
 458137 string characters out of 503842
 738532 words of memory out of 300
 29310 multiletter control sequences out of 15000+20
 9330 words of font info for 51 fonts, out of 300 for 9000
 670 hyphenation exceptions out of 8191
 40i,7n,43p,500b,80001s stack positions out of
5000i,500n,1p,20b,8s
Output written on 02944.pdf (79 pages).


I have tried increasing the 'save size' above 8, but it doesn't 
seem to go any higher. :(


This occurs when the package is loaded, regardless as to whether we 
specify words to index or not.


We tested with just XeSearch loading, and the same error occurred.

We would really appreciate any advice on this.


Without a minimal example, there isn't much I can do. But possible loops 
are described on page 5 of the doc. Are you sure you're not in such a case?

(TeX capacity is generally exceeded because it has entered a loop.)

Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Kerning flaw with MinionPro & XeTex

[Paul Isambert]

Le 07/02/2011 19:10, Peter Dyballa a écrit :


Am 07.02.2011 um 18:16 schrieb Khaled Hosny:


I'm rather jobless


Sounds Egyptian...


Are you trying to make some geopolitical statement or just wielding 
disparaging remarks, Peter?


Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Unexplained behavior

[Paul Isambert]

Le 15/01/2011 22:44, Bogdan Butnaru a écrit :

On Sat, Jan 15, 2011 at 20:01, Paul Isambert  wrote:

\thinspace is a \kern, which adapts to the mode it is in. What you want is
an horizontal space, but what happens is a vertical one, because the \kern
occurs in vertical mode (TeX is between paragraph at the time when \sepdash
occur, and between paragraph you're basically in vertical mode). You have to
begin the \sepdash macro with \leavevmode, so TeX switches to horinzontal
mode and typesets a horizontal space.

Oh, thanks for the explanation. It fixed that problem, but then I
noticed another one. I went through a few variations and I can’t get a
version that does what I want no matter what. Here’s what I’ve tried:

I want a typed em-dash to
1) in running text, be typeset with a small space around it
1a) ideally the space should be thin even if the source contains
spaces around it
1b) ideally the space should be glue rather than a kern, so it can
stretch a bit in stretched lines
2) line breaks should be forbidden before a dash, but should be allowed after
3) if a dash begins/ends a line, the space before/after it should disappear
4) and there should be no weird behavior otherwise...


1a) You unskip, very well.
1b) Allright, but an \hskip without plus/minus component doesn't stretch 
or shrink. (I've seen such a glue in your code.)
2) and 3) seems contradictory; if linebreak can't happen before a dash, 
how can it starts a line? You mean it starts a paragraph?

As for line ends, don't worry, space removal is ensured.

Your code wasn't minimal enough for me to try to make sense of it. I'll 
also try to honor point 5 in your next mail, but that is a hack; 
interchartoks would be better. Anyway here's a solution (untested):



\def\thedash{—}
\newskip\dashskip
\dashskip=.1em plus .1em % Or whatever else.

\def\mydash{%
  \unless\ifvmode
\unskip
\nobreak
\hskip\dashskip
  \fi
  \thedash
  \checkpunctuation
}

\makeatletter
\def\checkpunctuation{%
  
\@ifnextchar,{}{\@ifnextchar.{}{\@ifnextchar:{}{\@ifnextchar;{}{\hskip\dashskip%

% You should actually call with all the necessary characters.
}
\makeatother


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Unexplained behavior

[Paul Isambert]

Le 15/01/2011 19:44, Bogdan Butnaru a écrit :

Hello! I encounter funny behavior when compiling a document; small
example below my signature. If you look very carefully, the line that
begins with \sepdash is typset slightly farther away from the line
above it than the other two lines are.

I have a custom macro for typesetting em-dashes with a bit of space;
it’s longer than the one in the example, but this is the shortest that
still exhibits the problem. Note that if a simple em-dash is used, or
if the spaced one is not at the start of a line, the line is not
spaced more than usual. The extra space is subtle, but I’m typesetting
a document with an exact number of lines on the page and it complained
of an underfull vbox.

I’m very curious why this happens; nothing I know about TeX suggests
what’s the problem. (I’d also like a solution if possible, but it’s
not that much of a big deal, I can use a different macro to
work-around the problem.)


\thinspace is a \kern, which adapts to the mode it is in. What you want 
is an horizontal space, but what happens is a vertical one, because the 
\kern occurs in vertical mode (TeX is between paragraph at the time when 
\sepdash occur, and between paragraph you're basically in vertical 
mode). You have to begin the \sepdash macro with \leavevmode, so TeX 
switches to horinzontal mode and typesets a horizontal space.


Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Auto Font and Language Package in XeTeX

[Paul Isambert]

Selon Arthur Reutenauer :

> > Incidentally, does anyone know whether there is a LuaTeX version of the
> > XeTeXintercharclass behaviour that would let this package be rewritten
> > for LuaTeX with minimal effort?
>
>   Paul Isambert has written code to that effect, but I'm not sure he has
> made it into a package yet.


I haven't indeed. It's quite low on my priority list, all the more as mimicking
interchartoks isn't totally possible in LuaTeX, although the most significant
part of the mechanism can be reproduced.

Anyway judging from what I understand Michiel's package does, an
interchartoks-like code in LuaTeX won't work, because it'll really be an
``inter-node'' mechanism, and (glyph) nodes already have their fonts attached to
them, whereas the package is supposed to change fonts.

The solution would rather be: get the nodes as soon as possible, e.g. in the
ligaturing callback, and set the font number for each node according to its
unicode value. That means no such thing as "\fontspec{A font}" is usable here;
instead, you must go low-level and grab the fonts by their numbers. Such numbers
can be retrieved from the control sequences passed to the \font primitive with
Lua's font.id(). An extension to fontspec would be infinitely simpler than
an independent package.

Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] [OT] character encoding ideas [was: Re: Strange hyphenation with polyglossia in French]

[Paul Isambert]

 Le 21/10/2010 18:18, Arthur Reutenauer a écrit :

I've watched "House" with pleasure for a number of years.  It's taken me
until Series 5, which I'm just catching up on, to realize that House's boss
is "Dr Cuddy" not "Dr Cutty".  The actors say /cuddy/ which I assumed was
American for British /cutty/.

   Indeed, I had the exact same impression :-)


Common neutralization in American English: /d/ and /t/ are pronounced 
the same in some places, namely as /?/.
You can see all those sounds nicely pronounced here: 
http://www.shef.ac.uk/ipa/symbols.php

And I mean /see/, not simply /hear/.
Fortunately, spelling (in alphabetical writings, I mean) is 
phonological, not phonetic, otherwise Unicode would implode.

Yes, that's totally off-topic. Sorry Mojca. :)

Paul


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Strange hyphenation with polyglossia in French

[Paul Isambert]

 Le 17/10/2010 11:29, Cyril Niklaus a écrit :

In the meantime, the "solution" I used was to change fonts…


That basically disables hyphenation for this word, like would \/.

I noticed that if I wrote l'in\-formation, it would then hyphenate at the 
suggested point and not after the apostrophe.


Yes, explicit hyphenation prevents TeX from hyphenating elsewhere.

Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Localized XeLaTeX: was Greek XeLaTeX

[Paul Isambert]

 Le 17/10/2010 11:10, Ulrike Fischer a écrit :

Am Sat, 16 Oct 2010 16:24:44 +0200 schrieb Wolfgang Schuster:


Would this replace every occurence of "im" in the input? Including
the "im" in \scratchdimen, the "im" in the second 1im and the "im"
in immens?

Yes. This is why I said that the solution cannot work out-of-the-box
(it could work for a limited number of cases).



Another way is to use the string library from lua to replace μμ with mm:

They are a lot of way to replace two input chars by two others. My
editor (winedt) can do it in the background without any problems
when saving and restoring a file.

But this doesn't solve the problem that you don't want to replace
every occurrence of the two chars but only some - and that there
isn't a rule/regex or something like that to discern the one from
the other. What you would need is a primitive command or a callback
which allows to extend the list of units which can be used with
\vskip etc. As long as this doesn't exist you will have to mark one
of the sets somehow.


That would be a very good idea and I more or less feature-requested it 
this summer on the LuaTeX list. But the LuaTeX team already has much 
going on!
Besides localized units to solve the problem at hand here, one could 
define arbitrary units and use them as the basis of one's design. Or one 
could redefine existing units, for instance setting TeX's English point 
``pt'' to the Postscript point ``bp''.


Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Localized XeLaTeX: was Greek XeLaTeX

[Paul Isambert]

 Le 16/10/2010 16:43, Herbert Schulz a écrit :

On Oct 16, 2010, at 9:36 AM, Philip Taylor (Webmaster, Ret'd) wrote:



Wolfgang Schuster wrote:


Another way is to use the string library from lua to replace μμ with mm:

Is "μμ" really the Greek abbreviation for millimetres ?  If so,
how do the Greeks abbreviate micrometers (= microns, "μ") ?

Philip Taylor

Howdy,

I thought the symbols that are used for different units are set by 
international standards. Do you really want to spend time localizing something 
such that nobody else will ever understand it?


The people speaking the same language as you is not exactly ``nobody 
else''...



Don't you think everyone should attempt to learn the standards so we can talk 
to each other?


Yes, but suppose you're Electra, the OP's nine year old daughter; not 
only do you have to learn (pseudo-)words you don't understand, but you 
have to learn them with an alphabet that's not yours. Plus you have to 
learn (La)TeX, of course.


I think there should be experts, perhaps, that speak an international 
language, be it English or Latin or Warlpiri, but that solutions should 
be found to help people that don't want to or can't learn that 
international language; and experts should be bridges between an 
international community and a local one. It's easy to say "Just learn 
English!", but what if, as Khaled has remarked, TeX and its commands 
were written in Arabic? I for one wouldn't be using it, simply because I 
would have to learn everything as ideograms, which would be too much 
when added to the burden of learning TeX itself. And I guess I wouldn't 
be the only one in that case.


I think we'll be more of a community when we share the program, although 
not the language -- than in the current state where people simply do not 
learn the program, because of its language, and share nothing.


As for the OP's demand, I'm disappointed Philip hasn't devised the 
obvious solution yet (although I haven't read all the messages): use 
plain TeX! Since you'll have to write most macros yourself anyway, you 
can write them in Greek! (Rewriting plain.tex in Greek, and adding a 
translation of all primitives, shouldn't take too long.) Plus, since 
nobody is going to be able to help you for most of your problems, you 
don't mind if they can't read your control sequences :)


Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Strange hyphenation with polyglossia in French

[Paul Isambert]

 I can't answer your main question (about hyphenation after an 
apostrophe), but there are some points I can explain.



Le 16/10/2010 11:47, Cyril Niklaus a écrit :

In making the small version I include here, I also noticed something 
surprising: the hyphenation changed depending on the length of the text I cut 
*after*. Leaving one sentence or two did not give the same results. Cutting 
immediately after the sentence gave the correct l'in-formation and  
l'infor-mation was what I got when cutting before De toute part.


That's absolutely normal, that's even the reason why we use TeX :)
TeX builds a paragraph as a whole; if you remove some words at the end 
of your paragraph, it might change its entire shape.



I also noticed that including or not
\defaultfontfeatures{Mapping=tex-text}
changes things quite a bit while \frenchspacing did nothing obvious. I thought 
it would deal with spaces around the guillemets etc. but no. I'm wondering why 
I bothered including it. Is that a benefit from polyglossia?



\frenchspacing has nothing to with polyglossia, and it /is/ extremely 
important, even though you might not notice at once. It's a macro 
inherited from plain TeX, whose effect is to disable extra space after 
strong punctuation marks (e.g. a period), which extra space is used in 
(some flavors of) English typography. So keep it, although indeed it 
doesn't deal with space around guillemets.


Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Bidipoem for dialogue poetry

[Paul Isambert]

 Le 12/10/2010 01:53, Gareth Hughes a écrit :

Paul Isambert wrote:

Ok, the following works on your file, but I don't know how robust it is:

%%%

\newcount\LineNumber \newcount\templinenumber
\newdimen\linenumberskip \linenumberskip=6em
\chardef\linestep=2
\def\poemlinenumber{%
   \advance\LineNumber1
   \templinenumber=\LineNumber
   \computelinenumber
   }
\def\computelinenumber{%
   \ifnum\templinenumber>\linestep
 \advance\templinenumber-\linestep
 \expandafter\computelinenumber
   \else
 \ifnum\templinenumber=\linestep
   \leavevmode\rlap{\kern\linenumberskip\the\LineNumber}%
 \fi
   \fi
   }
\newenvironment{numberedpoem}
   {\everypar{\everypar{\poemlinenumber}}%
\begin{traditionalpoem}}
   {\end{traditionalpoem}}

%%%

You poem should now be enclosed in the "numberedpoem" environment.
You can change \linestep (on line 3) to any value; if it is set /n/,
every /n/th line number is printed.
You can change \linenumberskip (on line 2), which sets the distance of
the line number to the margin.
This is not thoroughly tested! Sorry for the syntax, it's not LaTeX-like
(but you made me -- although you didn't ask! -- download so many
packages so your file can work than I need a little revenge :) ).

Best,
Paul


Thank you, Paul, for showing me how to do this. It looks good and is
quite flexible. I have a couple more questions, if I may.

1) What is the best way of changing the positioning of the numbers so
that they are on the right of the poem, or that they are on the inner or
outer edge in documents that define these things? Is this best done by
altering \linenumberskip?



For this point I have the following solution (needs two runs):

\makeatletter

\d...@writelinenumber#1{%
  \wri...@mainaux{%

\noexpand\expandafter\gdef\noexpand\csnam...@linenumber\noexpand\endcsname{\the\count0}}% 


  }
\newcou...@linenumbercount
\newcount\LineNumber \newcount\templinenumber
\newdimen\linenumberskip \linenumberskip=5em
\chardef\linestep=2
\long\def\poemlinenumber{%
  \advance\LineNumber1
  \templinenumber=\LineNumber
  \computelinenumber
  }
\def\computelinenumber{%
  \ifnum\templinenumber>\linestep
\advance\templinenumber-\linestep
\expandafter\computelinenumber
  \else
\ifnum\templinenumber=\linestep
  \global\advan...@linenumbercount1
  \expandaft...@writelinenumber\expandafter{\the\@linenumbercount}%
  \ifcsname\t...@linenumbercount @linenumber\endcsname
\ifodd\csname\t...@linenumbercount @linenumber\endcsname\relax
  
\leavevmode\rlap{\kern\dimexpr\hsize-\linenumberskip\relax\the\LineNumber}%

\else
  \leavevmode\rlap{\kern\linenumberskip\the\LineNumber}%
\fi
  \else
\leavevmode\rlap{\kern\linenumberskip\the\LineNumber}%
  \fi
\fi
  \fi
  }
\newenvironment{numberedpoem}
  {\everypar{\everypar{\poemlinenumber}}%
   \begin{traditionalpoem}}
  {\end{traditionalpoem}}


\makeatother




2) As it stands, a blank line, indicating a stanza break, is counted as
a line of the poem. How can this code be altered so as not to count the
blank lines between stanzas?
For this one, though, I don't have any solution. I've investigated 
bidipoem a bit, and it does its job with alignments, and doesn't treat a 
blank line simply as \par. So our macro fires on blank lines...


Of course a hack of bidipoem is possible (but I won't do it, no time to 
do so), but I think it'd be easier to ask the author to implement such a 
feature (line numbers in poems aren't uncommon...). Or find another way 
to input a blank line...


Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Bidipoem for dialogue poetry

[Paul Isambert]

 Le 10/10/2010 17:26, Gareth Hughes a écrit :

Paul Isambert wrote:

That one is harder. Line number are no simple matter with traditional TeX.
Question: does bidipoem starts a new paragraph with every line? Then
something might be doable with \everypar.
Just try this in the poem environment: \everypar{test}. If ``test''
appears at the beginning of every line, then I might try to find a
solution.

Hmm. Within the environment \everypar has no effect, but given outside
the traditional poem, but within the font changing environment, it
prints on each line including the  the 'zeroth' line. I'm not sure if
this is the right way to do this, how might this work?


Ok, the following works on your file, but I don't know how robust it is:

%%%

\newcount\LineNumber \newcount\templinenumber
\newdimen\linenumberskip \linenumberskip=6em
\chardef\linestep=2
\def\poemlinenumber{%
  \advance\LineNumber1
  \templinenumber=\LineNumber
  \computelinenumber
  }
\def\computelinenumber{%
  \ifnum\templinenumber>\linestep
\advance\templinenumber-\linestep
\expandafter\computelinenumber
  \else
\ifnum\templinenumber=\linestep
  \leavevmode\rlap{\kern\linenumberskip\the\LineNumber}%
\fi
  \fi
  }
\newenvironment{numberedpoem}
  {\everypar{\everypar{\poemlinenumber}}%
   \begin{traditionalpoem}}
  {\end{traditionalpoem}}

%%%

You poem should now be enclosed in the "numberedpoem" environment.
You can change \linestep (on line 3) to any value; if it is set /n/, 
every /n/th line number is printed.
You can change \linenumberskip (on line 2), which sets the distance of 
the line number to the margin.
This is not thoroughly tested! Sorry for the syntax, it's not LaTeX-like 
(but you made me -- although you didn't ask! -- download so many 
packages so your file can work than I need a little revenge :) ).


Best,
Paul




--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Bidipoem for dialogue poetry

[Paul Isambert]

 Le 10/10/2010 16:51, Gareth Hughes a écrit :


Does anyone have any thoughts how line numbers might be handled in this
bidipoem environment? None of the usual packages that provide line
numbering play nicely, and I can't work out from the code how best to do it.


That one is harder. Line number are no simple matter with traditional TeX.
Question: does bidipoem starts a new paragraph with every line? Then 
something might be doable with \everypar.
Just try this in the poem environment: \everypar{test}. If ``test'' 
appears at the beginning of every line, then I might try to find a solution.


Paul




--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Bidipoem for dialogue poetry

[Paul Isambert]

 Le 10/10/2010 14:16, Philip Taylor (Webmaster, Ret'd) a écrit :

Paul, in which dialect(s) of TeX does \quitvmode exist ?

Paul Isambert wrote:


\def\persona#1{%
\quitvmode\llap{\hbox to {#1\hfil}}%
}




Oh, right.
Gareth, you should use \leavevmode instead of \quitvmode, which is a 
pdfTeX primitive that doesn't exist in XeTeX.


Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Bidipoem for dialogue poetry

[Paul Isambert]

 Le 10/10/2010 00:48, Gareth Hughes a écrit :

Gareth Hughes wrote:

As you can see from my attached example, the persona is included as a
part of the first hemistich, but to make the lines look nice it is also
included in the following three hemistiches within \phantom{} commands.
I also need to set \poemcolsep to -1em to close the 'phantom' gap. I
hope that makes sense.

Well, the problem is that it's not a pretty workaround and the beginning
of the first hemistich of each line doesn't line up, because personae
are of different lengths. I suppose I need some means of marking up each
line as having

persona: first-hemistich&  second-hemistich

OK. I think \llap is useful here to give the personae and there phantom
versions zero width aligned right.


That's what I would have said. I consider \llap probably one of the more 
useful macros in TeX.

Note that if you still want personae flushed left, you can use:

\def\persona#1{%
  \quitvmode\llap{\hbox to {#1\hfil}}%
}

with  wide enough to accommodate all names.

Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] How could xetex find texlive fonts on a mac?

[Paul Isambert]

 Le 04/10/2010 16:35, ami a écrit :
> Thanks for your advises . I am new to Tex and i am interesting in it .
>
>
Good luck then, and have fun! And don't hesitate when you have a
question: people on this list, and on others as well, generally answer
them all, no matter whether it requires advanced wizardry or basic
knowledge.

Paul


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] How could xetex find texlive fonts on a mac?

[Paul Isambert]

 Le 04/10/2010 06:25, 德柳 邓 a écrit :
I'am a newer for texlive . I have installed texlive 2010 
universal-darwin under command line for mac (not Mactex).

--
1. I tried to compile
$ xetex opentype-info.tex
Then i got a error :
This is XeTeX, Version 3.1415926-2.2-0.9997.4 (TeX Live 2010)
 restricted \write18 enabled.
entering extended mode

(/Users/dang/Applications/texlivee/2010/texmf-dist/tex/xetex/xetexfontinfo/opent
ype-info.texkpathsea: Invalid fontname `Latin Modern Roman/ICU', 
contains ' '


! Font \testfont="Latin Modern Roman/ICU" at 12.0pt not loadable: 
Metric (TFM)

file or installed font not found.
l.26 \font\testfont="\myfontname/ICU" at 12pt
?



XeTeX is telling you he can't find the font. You don't have it on your 
computer, because it should be installed. Try to download the ``lm'' 
package with TeXLive manager (tlmgr).



Following the second given advice  I found on the texlive-en.pdf :
(If you do not have sufficient privileges to carry out the steps 
above, you can instead do the following to make the TEX Live fonts 
available to you as an individual XeTEX user)


$ cp ./texlive-fontconfig.conf  /Users/dang/.fonts.conf
$ fc-cache -fv

I then ran xetex again but i got the same error. how can i do then ?
---
2.   I tried latex pain.tex
i got some  error :
(/Users/dang/Applications/texlivee/2010/texmf/tex/generic/hyphen/hyphen.tex
! Patterns can be loaded only by INITEX.
l.5 \patterns
 { % just type  if you're not using INITEX
?
***
so are there anyting else should be configed ?


plain.tex (not ``pain.tex'', although some people will be pleased by 
your typo :) ) is the source code for a format; it is not supposed  to 
be compiled by itself (it's not a document).


TeXLive is correctly configured, but you should try to run your own 
documents. My question is: you're new to TeXLive, but are you new to 
TeX? In which case you should read a proper introduction, either to 
plain TeX:


http://www.ctan.org/tex-archive/info/impatient/book.pdf
[+ find a copy of the TeXbook]

or to LaTeX (choose your language!):

http://www.ctan.org/tex-archive/info/lshort/

or to ConTeXt:

http://www.pragma-ade.com/general/manuals/ms-cb-en.pdf

You can't use TeX without some learning before, unless you're willing to 
spend many sleepless nights on it (which you'll do anyway).


Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] arabxetex vs. xepersian

[Paul Isambert]

 Le 03/10/2010 14:52, Tobias Schoel a écrit :

I'm no linguist. Sorry if I have uttered old and overcome thoughts.


Let's say they're controversial at best. But not false, mind you: just 
very hard to assess.


As far as I know, languages do lack things indeed: some phonems, 
interpunctuation, grammar, ...


Yes, of course. I was speaking about the lexicon, actually, and the 
ability to express thought.




Political use of phonetics: the German language is lacking the 
difference between the chinese phonems q,zh,ch,x,sh, ... The 
consequence is that Chinese was interpreted as kauderwelsch (english 
translation?) and thus the Chinese as "dumb". This was used for 
propaganda against China during imperialism.


Well that's a /reflexion/ on phonetics, it's not phonetics itself that 
is used. Such considerations are of course frequent. See Rousseau's 
comparison of the Italian and German languages in his /Essai sur 
l'origine des langues/. And see accents, of course: one person's accent 
is laughable (or, less frequently, poetic) to another. In France the 
accent from Québec is often felt as comical -- until I was told (I can't 
remember by whom) of a French professor who went to Québec and couldn't 
understand why the entire classroom was laughing at him. His accent, of 
course!


In that way, phonetics does indeed play a great role in politics: in 
France at least, you'll never hear a politician with an accent that is 
considered `popular'.


Globally, indeed, languages are often barriers, generally because 
they're ill-understood, sadly. People often think there is a `right' way 
of saying things, which is absurd.


Am I not somewhat off-topic? :)

Paul



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] arabxetex vs. xepersian

[Paul Isambert]

 Le 03/10/2010 14:16, Tobias Schoel a écrit :



That's not phonetics, that's politics. Nothing to do with Persian/Farsi.


Language has always been an important weapon in politics. People think 
in the languages they speak. If a language lacks something, then the 
thinking of the speakers of this language will probably lack it as 
well. And politics is always based on lacks in the thinking of the 
people the politics are aimed at.
On the relation of language and politics, you're right... except not in 
the sense you mean it. The relation between thought and language is far 
from obvious. Your position is extreme Sapir-Whorf, which as far as I 
know, has been corroborated only in some very simple areas (colors, 
prepositions...).  Now the _use_ of a language is another matter, as is 
the influence of culture. But a ``language lacking something'' is not an 
entity you can spot easily.


Anyway I was speaking about phonetics, and I've never seen any political 
use of phonetics (barring puns).


Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] arabxetex vs. xepersian

[Paul Isambert]

 Le 03/10/2010 14:12, Vafa Khalighi a écrit :

We say Parsi and that is it. Sorry but your arguments are nonsense.

As you wish. Except you said "Persian" :)

Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] arabxetex vs. xepersian

[Paul Isambert]

 Le 03/10/2010 13:51, Vafa Khalighi a écrit :


We say Parsi, the international community says Persian. History says 
Persian, where does Farsi come from? As I said before, you should read 
some history before commenting unwisely?
It's not a matter of history, it's a matter of phonetics. "Farsi" comes 
from "Parsi" in some phonetic system. It is not fake, it's just the 
transliteration of a pronunciation. I'm sorry to tell you there's no 
real name for your language, since there's no real name for anything. In 
French we say "Persan", with no semi-vowel "i" as in "Persian" (and a 
nasalized "a", despite the spelling, not to mention the pronunciation of 
"r"). Would you say it's fake? Or would you say that the English 
pronunciation is fake just because in English you don't use nasalized 
vowels? That's the same thing with p/f, except it looks more dramatic, 
because of the spelling. But I'm sorry to say that "Farsi" is closer to 
"Parsi" than "Persian" is, if you count differences.


And anyway: the name of your language depends on the language in which 
you say it. And no language is better than any other to represent things 
-- even itself.



at least you know that arabs have tried their best to change the name 
of "Persian gulf" into Arabian gulf but they always have failed to do so.

That's not phonetics, that's politics. Nothing to do with Persian/Farsi.

Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] arabxetex vs. xepersian

[Paul Isambert]

 Le 03/10/2010 13:34, Vafa Khalighi a écrit :



On Sun, Oct 3, 2010 at 10:28 PM, Arthur Reutenauer 
> wrote:


On Sun, Oct 03, 2010 at 10:15:34PM +1100, Vafa Khalighi wrote:
> Its Persian not Farsi. Farsi is the fake name that arabs give to our
> language as they have no "p".

 Vafa, what did we say about making such statements on a public
mailing-list?


As an Iranian Zoroastrian, I could not ignore my feelings. Sorry. but 
I did not say anything offensive, I just said that Farsi is fake. You 
should read some history.
"Persian" is an English pronunciation, "Farsi" an Arabic one. Both 
derive from the same word. I can't see why one is fake and not the 
other. Like saying the real name of French is Französich, for some 
reason having to do with German phonetics...


Plus in good phonology, if there's no "p" then you can't consider that 
"f" represents the sound /f/; it represents an archiphonem of both /p/ 
and /f/. So it's "parsi" after all.


Paul


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Tables

[Paul Isambert]

 Le 03/10/2010 00:29, Mike Maxwell a écrit :

On 10/2/2010 3:52 PM, Paul Isambert wrote:

And I'll add: printing a corpus with annotations that don't show up but
are fed to LuaTeX for statistics, and returned as tables. What I'm doing
right now.


Interesting.  We're producing grammars.  They're XML (if you want to 
mark structure, use XML!), 


Yes, probably. But my knowledge of XML is not very good, although I 
doesn't seem very complicated.


and they get converted to XeLaTeX for typesetting (if you want to 
typeset, use LaTeX!). 


No, use plain TeX :)



Automatically produced tables--which I gather is what you're producing 
from your corpus--might also suffer from that problem; I'm hoping you 
may have come up with a solution.  Or are they all short and narrow 
enough that you know in advance that they'll fit?


They're short, so they fit. Anyway, even if I had a solution, it would 
be plain TeX. By default, plain TeX tables can break across pages, since 
they're just lists of horizontal boxes (although it doesn't mean headers 
are automatically inserted).


(BTW, did you mean they were sent to R for statistics, rather than 
LuaTeX?  Or does LuaTeX allow you to send things to Lua internally?)
By Lua, I mean LuaTeX. The statistics are quite simple, and descriptive. 
So I make some basic arithmetic operations with the Lua side of LuaTeX, 
without sending anything anywhere. I guess you could write more 
complicated stuff, though.


Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] XeTeX in lshort

[Paul Isambert]

 Le 02/10/2010 22:36, Philipp Stephani a écrit :

Am 02.10.2010 um 21:52 schrieb Paul Isambert:


Le 02/10/2010 21:22, Alan Munn a écrit :

On Oct 2, 2010, at 2:47 PM, Philipp Stephani wrote:


Am 30.09.2010 um 09:36 schrieb Tobias Schoel:


Hi,

there are three kinds of people who should learn TeX&Co:
- those who absolutely need TeX, because no other system let's them produce the 
documents they have to (all this linguistis and co. [don't take offense, I have 
no idea of the professions around this topic])

Please elaborate on why they should use TeX. Personally I think that TeX is 
quite inappropriate for linguistics.

I'm not sure that this discussion should really continue, but what do you know 
about linguistics that would give you such an opinion?  LaTeX is very 
appropriate for linguistics, and many working linguists are using it (not to 
mention that it is used to typeset various linguistics journals.)  As I 
mentioned in a previous message it provides  many concrete advantages: 
automatic numbering/referencing of linguistic examples, automatic aligning of 
foreign language words/translations, automatic syntactic tree drawing; a full 
range of logic symbols, easy access to phonetic fonts etc., not to mention 
other basic academic requirements such as citations and bibliographies.  Doing 
most of this in Word is either not trivial or not possible.

And I'll add: printing a corpus with annotations that don't show up but are fed 
to LuaTeX for statistics, and returned as tables. What I'm doing right now. 
With reference from main work to example number, mention of origin, etc.

At the very least, I'd concede TeX is not mandatory for linguistics, as 
anything else, but ``inappropriate'' lets me wonder, and I'd require an 
explanation,  if transient trollism wasn't an option, as suggested by Alan.

Well, I hope you accept lack of information as valid reason. I'm not a linguist 
and don't know much about the exact requirements in that field, but I haven't 
seen much LaTeX usage outside of the world of math and natural science, that's 
why I was a bit surprised.

Many books in linguistics are typeset with LaTeX (and many aren't); and 
most if not all my fellows in PhD use LaTeX to typeset their 
dissertations, without advisors forcing them to do so. And the fields 
are quite diverse: experimental phonetics, phonology, syntax, semantics, 
acquisition, field linguistics... While I have my doubts about the first 
advantage of LaTeX as stated in lshort (since that's what we're talking 
about), namely that ``Professionally crafted layouts are available, 
which make a document really look as if `printed','' nobody can deny 
that a LaTeX document looks better than a Word document (which doesn't 
mean it doesn't look as LaTeXish as a Word document looks Wordish).


As for structure, of course you can say {\bf Title} in TeX to produce a 
section title, but \section{Title} isn't more complex, so you use it. In 
Word, on the other hand, clicking ``Bold'' is simpler than fetching a 
style (as far as I can tell). Most people use LaTeX like they use Word: 
they don't ask many questions nor do they try to understand much of 
what's going on. Basically, they do what they're told to do. But the 
underlying software is simply better.


Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] XeTeX in lshort

[Paul Isambert]

 Le 02/10/2010 21:22, Alan Munn a écrit :

On Oct 2, 2010, at 2:47 PM, Philipp Stephani wrote:


Am 30.09.2010 um 09:36 schrieb Tobias Schoel:


Hi,

there are three kinds of people who should learn TeX&Co:
- those who absolutely need TeX, because no other system let's them 
produce the documents they have to (all this linguistis and co. 
[don't take offense, I have no idea of the professions around this 
topic])


Please elaborate on why they should use TeX. Personally I think that 
TeX is quite inappropriate for linguistics.


I'm not sure that this discussion should really continue, but what do 
you know about linguistics that would give you such an opinion?  LaTeX 
is very appropriate for linguistics, and many working linguists are 
using it (not to mention that it is used to typeset various 
linguistics journals.)  As I mentioned in a previous message it 
provides  many concrete advantages: automatic numbering/referencing of 
linguistic examples, automatic aligning of foreign language 
words/translations, automatic syntactic tree drawing; a full range of 
logic symbols, easy access to phonetic fonts etc., not to mention 
other basic academic requirements such as citations and 
bibliographies.  Doing most of this in Word is either not trivial or 
not possible.


And I'll add: printing a corpus with annotations that don't show up but 
are fed to LuaTeX for statistics, and returned as tables. What I'm doing 
right now. With reference from main work to example number, mention of 
origin, etc.


At the very least, I'd concede TeX is not mandatory for linguistics, as 
anything else, but ``inappropriate'' lets me wonder, and I'd require an 
explanation,  if transient trollism wasn't an option, as suggested by Alan.


Paul


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] OTF font question

[Paul Isambert]

I use FontMatrix, which I find very good.

Best,
Paul

Selon Manfred Lotz :

> There are OTF fonts where the their documentation states that certain
> Unicode ranges are partially supported. However, the documentation
> doesn't tell what exactly is supported.
>
> Is there a tool available that is able to list the unicode
> characters a font actually supports?
>
>
>
> --
> Manfred
>
>
>
>
> --
> Subscriptions, Archive, and List information, etc.:
>   http://tug.org/mailman/listinfo/xetex
>




--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] XeTeX documentation "initiative"

[Paul Isambert]

Selon John Was :

> Hello
>
> I haven't been following the proposals in detail but it seems to me that the
> suggestions are overwhelmingly weighted in favour of XeLaTeX users - which
> is fine as long as someone is working on a plain XeTeX manual of comparable
> scope.  I don't use (Xe)LaTeX myself, and I think the applies to a number of
> regular contributors to this list - I still reach fo The TeXbook when I want
> to do something non-routine, and would hope that all the extra commands
> available in (plain) XeTeX might be documented in a comparably rigorous
> manner so that one isn't left to stumble across potentially useful features
> almost by accident.

There's at least Will's XeTeX Reference.

But I've been worried too about the visibility of plain TeX (which is rather
"do-it-yourself TeX"), and not only in the context of XeTeX (I use LuaTeX,
actually). I guess the situation might stem from the fact that plain TeX users
are generally able to solve most of their problems by themselves (since they
also /create/ them by themselves), so plain TeX is seldom discussed on lists.
Thus, LaTeX or ConTeXt users have few invitations to plain TeX, not to mention
total newbies.

I've been thinking for a while about some kind of plain TeX wiki, which would at
the very least list existing packages for plain, give example solutions to basic
problems (references, tables of contents...), and perhaps address more advanced
topics (e.g. the output routine, of course, but also OpenType fonts in LuaTeX,
etc.). The gist of the thing would be something like "total control of
typographic operations". I have no time to do it now, let alone build it from
scratch, but I'll consider it again somewhere in the future.

And but so I didn't mean to step on the XeLaTeX companion's toes, which must be
strong and unbreakable anyway :)

Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] XeTeXpdffile media box etc

[Paul Isambert]

Selon Heiko Oberdiek :

> On Thu, Sep 09, 2010 at 09:03:55AM +0200, Paul Isambert wrote:
>
> > \pdfpagesattr{
> >   /CropBox [llx lly urx ury]
> >   /MediaBox ...
> >   ...
> > }
>
> NO, don't add /MediaBox. It's set by pdfTeX and can be configured
> by \pdfpagewidth and \pdfpageheight.
>
> The other boxes can be set this way (or using \pdfpageattr).
> However dealing with \pdfpageattr(s) is very nasty in general.
> * Previous contents should be included.
> * Setting the same key twice should be avoided.

The idea is to produce a test file so Will can try including it in another
document to test the options, not to do anything meaningful with \pdfpageattr,
which indeed is a pain in the, e, head. Actually that's the s-less version I
meant (\pdfpageattr, not \pdfpagesattr); the PDF Reference doesn't flag the
Bleed-, Trim- and ArtBox as inheritable, so I guess using \pdfpagesattr won't
work.

I didn't know about MediaBox, but it makes sense -- even though the pdfTeX
manual gives /MediaBox as an example of an attribute in \pdfpagesattr.

Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] XeTeXpdffile media box etc

[Paul Isambert]

Selon Will Robertson :

> Hi,
>
> Thanks Paul and William for the useful info. Another clarification:
>
> > Crop, Bleed and Trim are standard printing terms and the usage reflects
> > that. Media is used to describe the underlying page size to which one
> > would likely be printing the file and art is what one wants people to
> > see.
>
> And how do these behave? In all cases, is the PDF cropped to whichever
> bounding box is specified? Or do they just relate to the alignment of
> the inserted box? Or does it vary between them?

The pdfTeX manual states:

"one may also decide in the pdf image case, which page box of the image is to be
treated as a final bounding box."

I guess XeTeX works in the same way. So, for instance, you can include a page
with printer's marks (if you use the media box) or just some meaningful content
(if you use the art box). Anyway people likely to use the option probably know
what those boxes are, so stating that the mentioned box will be the bounding box
is enough, isn't it?

In any case, you can still produce a file with pdfTeX and specify the boxes with
different values:

\pdfpagesattr{
  /CropBox [llx lly urx ury]
  /MediaBox ...
  ...
}

where llx/lly = lower-left x/y and urx/ury = upper-left x/y, only numbers,
expressing dimensions in Postscript points (by default).

Then include the file in another one and try changing the option.

Best,
Paul






--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Change fonts for different environment/commands

[Paul Isambert]

Selon Philipp Stephani :

>
> Am 08.09.2010 um 08:46 schrieb Wilfred van Rooijen:
>
> > Hi all,
> >
> >> But why ?  What exactly do you dislike about the use
> >> of
> >> sans serif for headings ?  To my mind, and in a
> >> scientific
> >> as opposed to artistic context, sans serif headings with
> >> serif prose seem absolutely normal and fine.
> >
> > The age-old discussion as to whether or not sans-serif is evil or not. It
> is commonly stated that serif letters are more readable because the little
> serifs give a better visual baseline, with a more clear distinction between
> words and spaces. I have always had difficulty with accepting this wisdom. I
> think that there is also a cultural component and a component of "getting
> used to". Unless somebody can show me scientifically and statistically sound
> research which shows that serif if better than sans-serif, I am not willing
> to accept the common wisdom that serif is better than sans-serif and my
> opinion will remain that it is a matter of taste (*).
>
> There has actually been lots of research on this, with the result that there
> is no significant difference in legibility. Here is a nice discussion:
>
> http://www.alexpoole.info/academic/literaturereview.html
>
> I think almost everything in typography is due to historic happenstances (my
> anecdotal knowledge tells me that serifs were introduced by the Romans
> because they were easier to carve in stone) and is thus purely a matter of
> taste. Typographic "rules" are mere conventions or opinions of "experts" like
> Bringhurst, Tufte, Tschichold etc., and almost none of them would pass a
> scientific test. That doesn't mean that they are completely irrelevant:
> following traditions rather than breaking them is helps the visual
> representation stand back behind the contents.

Try a 30-cm-wide textblock in Punk Anno with negative leading, I guess it'll
pass all scientific tests :)

Everything is historical accident in typography, perhaps, but that doesn't mean
fruitless accidents haven't been pruned away, whereas fruitful ones have been
grown further (sorry for the bad metaphor in bad English).

And let's not forget that typography makes sense too, and that the form of a
book influences the acquisition of its content, even if it's just a matter of
"mood" or subconscious stimulation or I don't know what. Typography is not just
pretty fonts. I suppose only people with some typographic education are
consciously repelled by ugly books, but I bet that _everybody_ is influenced
anyway.

Finally: to break rules, you have to know them, otherwise you're just following
untold ones.

Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Change fonts for different environment/commands

[Paul Isambert]

Selon Wilfred van Rooijen :

> Hi all,
>
> > But why ?  What exactly do you dislike about the use
> > of
> > sans serif for headings ?  To my mind, and in a
> > scientific
> > as opposed to artistic context, sans serif headings with
> > serif prose seem absolutely normal and fine.
>
> The age-old discussion as to whether or not sans-serif is evil or not. It is
> commonly stated that serif letters are more readable because the little
> serifs give a better visual baseline, with a more clear distinction between
> words and spaces. I have always had difficulty with accepting this wisdom. I
> think that there is also a cultural component and a component of "getting
> used to". Unless somebody can show me scientifically and statistically sound
> research which shows that serif if better than sans-serif, I am not willing
> to accept the common wisdom that serif is better than sans-serif and my
> opinion will remain that it is a matter of taste (*).

Some authors say indeed that sans-serif fonts are easier to read, some say
they're equivalent to serif ones, so there's obviously no definitive truth about
that. And above all it greatly depends on the font used: Helvetica and Optima
are both sans serif, but they don't have the same readibility at all. The same
is true for serif too. Wilfred's right in stressing the importance of what one
is used to: "Readers read best what they read most", says Zuzana Licko (add a
caron to the "c"). I've had an interesting experience recently: I've read an
English novel, and immediately after I finished it I turned to an American one:
I was so used to single quotation marks for dialogs (English custom) that double
ones (American custom) really hindered my reading at the beginning, even though
I read American books more often than English ones.

Readability does not depend on the font only, anyway. Line width,
x-height/leading ratio, justification, not to mention printing (ever read a
cheap paperback in Sabon? well you can forget about its readibility), etc.


> Now, for the use of sans-serif and serif within the same document, I think
> that it is also a matter of taste. Some people may like it, others dislike
> it, and again, I think it has more to do with being used to something than
> with hard science.

My position, for what it's worth, is nonetheless that there should be as few
font variations as possible. First try with the normal text font for headings,
then perhaphs italics, then perhaps small caps, then perhaps the same font at
larger size, then perhaps bold, then perhaps switch to a sans-serif... Titles do
not have to scream, they are sufficiently different from the main text:
generally one line, unindented, with perhaps a section number, surrounded by
blank lines. LaTeX's default to big fat section title is unnecessary in most
cases, although it can make sense if a text has many interruptions (e.g.
equations) since the white space that surrounds them might be mistaken for
section break. Fat titles for reading on the screen is no bad idea either.

So, about unserifed section headings, yes, why not, "it's a matter of taste",
but there's so much more to typography than simply personal taste...

Best,
Paul



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] XeTeXpdffile media box etc

[Paul Isambert]

I guess a look at the PDF reference might be a good idea:

http://www.adobe.com/devnet/acrobat/pdfs/PDF32000_2008.pdf

Especially section 14.11.2 (pages 627-628) where those terms are defined for PDF
documents. Perhaps a word to ConTeXt's people too, since they're generally
oriented toward "real-life" typography, and I'm not sure they read this list?

Best,
Paul


Selon Will Robertson :

> Hi,
>
> I'm writing up the syntax of \XeTeXpdffile and \XeTeXpicfile and I'd
> like someone who knows better than I do to explain the optional
> argument to \XeTeXpdffile to control the bounding box of the graphic:
>
>  [ crop | media | bleed | trim | art ]
>
> Any volunteers? (If these are standard "industry" terms, is there a
> good reference page to link to, perhaps?)
>
> Also, is there a way to access this functionality through \includegraphics?
>
> Thanks,
> Will
>
>
>
>
>
> --
> Subscriptions, Archive, and List information, etc.:
>   http://tug.org/mailman/listinfo/xetex
>




--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] \botmark and \firstmark not working for me ...

[Paul Isambert]

Selon Ron Aaron :

> On Sunday 01 August 2010 12:41:35 Khaled Hosny wrote:
>
> > It is not like they are enemies or even commercial competitors, it is
> > all TeX and, if one's need can be achieved by this or that engine, then
> > be it. Not everything can be done with traditional TeX techniques, not
> > in a efficient way at least.
>
> True enough.

Damn. The humor in my remark about not advertising LuaTeX here didn't go
through. I dislike email communication for this reason exactly: only half of
what you mean actually reaches the reader. Smileys have their use, after all :)

LuaTeX could indeed easily go through the box's node list and retrieve all
migrating material. But there must exist a solution in TeX, since people have
used multi-columns in TeX for decades, and I don't like this solution escaping
me.

Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] \botmark and \firstmark not working for me ...

[Paul Isambert]

Selon Philipp Stephani :

>
> Am 01.08.2010 um 09:28 schrieb Ron Aaron:
>
> > On Sunday 01 August 2010 10:16:27 Paul Isambert wrote:
> >
> >> Indeed, the \mark won't end up on the main vertical list. In the latest
> >> TUGboat issue, Hans Hagen writes about this and proposes a nice
> >> solution... but with LuaTeX!
> >
> > Hmm.  I really need XeTeX, since it knows how to typeset complex languages
> > very well (and I really like the font-handling!).
>
> AFAIK LuaTeX can handle OpenType fonts as well (because it can use every Lua
> library). So you might give LuaTeX a try—probably in combination with
> ConTeXt, since LaTeX support for LuaTeX is still in an early stage.

Let's not advertise LuaTeX on the XeTeX list! (I'm a former XeTeX-user who moved
to LuaTeX, but XeTeX remains in my heart because it's the first time I used
True- and OpenType fonts in TeX... for the record, I think the first font was
Comic Sans MS, because it added an improbable twist to a situation I already
couldn't believe! First (and last) time in my life I found those glyphs
beautiful...)

Anyway Hans' code is far from trivial, and can't be duplicated on the fly, I
think.

Ron's problem is acknowledged on page 417 of the TeXbook, where the code for the
two-column index is given: "A more difficult approach would be necessary if the
index contained insertions (e.g., footnotes); fortunately it doesn't.
Furthermore, there is no need to use \mark [...]".

As for \unvbox, Ron, your \vadjust is unnecessary and indeed leads to bad
results. Anyway \unvbox in horizontal mode (your \line) turns to vertical mode,
that's why the columns appear on top of each other. As a replacement, I'd think
of \unvboxing in a vbox (to be shipped out) the first column and then \kern'ing
back to the origin of the box... but then one should \moveright for the right
column, but \moveright takes a \box, not an \unvbox, as its argument, so the
right column won't be unfolded. So it doesn't work.

I'm stuck. But I've learned there always exists a solution in TeX. Although the
code might be quite a hack!

Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] \botmark and \firstmark not working for me ...

[Paul Isambert]

Selon Ron Aaron :

> On Sunday 01 August 2010 06:23:19 Ron Aaron wrote:
> > On Sunday 01 August 2010 00:47:59 John Was wrote:
> > I wonder if my problem stems from the "mark" being
> > inside a vbox?  If that's the problem, I don't know how I would get around
> > it ...
>
> Argggh!  That is exactly what my problem is.  The "\mark{}" is inside a
> "vbox".  I need somehow to get it to show up in the main vertical list, but
> so
> far "\vadjust" hasn't worked for me...

Indeed, the \mark won't end up on the main vertical list. In the latest TUGboat
issue, Hans Hagen writes about this and proposes a nice solution... but with
LuaTeX!

So to keep with XeTeX, I wonder if a two-run process wouldn't be simpler: use
\write with an external file, which you \input on the next compilation.

But then a question: what is your \mark doing in \vbox if it is in the "body
text", as said in your first message?

Best,
Paul


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex