RE: [XP] Re: More comments on "Réflexions"

[Robert Keeble <RKeeble@xxxxxxxxx>]

> -----Original Message-----
> From: Olivier RANDIER [mailto:orandier@xxxxxxxxxxx]
> Sent: Tuesday, September 28, 1999 6:47 PM
> To: typographie@xxxxxxxx
> Subject: [XP] Re: More comments on "Réflexions"
> 
> >3bis. (words beginning with cap) except when starting a phrase
> >	=> breaks the flow for the reader (?)
> 
> No, the problem is that usually we need not to break word 
> beginning with a
> cap EXCEPT for words starting a phrase. If a phrase beginning 
> with a very
> long word starts at the end of the line, it's allways rejected at the
> following line and you get loose justification. When I have 
> this problem, I
> found a workaround consisting in replacing the cap of the 
> first word with a
> lower case with a cap attribute, but it's a hassle. So the 
> software should
> be able to treat differently common words at the beginning of 
> a phrase and
> _noms propres_ (I couldn't find the translation).

So...an option that allows/disallows hyphenating proper names...but with a
separate, related option to allow the break if the name starts a sentence,
and breaking it improves the justification.


> >4. in combinant words (which already have a hyphen)
> >	=> looks really horrible if they break
> Yes. Unless it has changed in 4.0, XPress allows hyphenation 
> of combinant
> word anywhere. It should only allow it at the hyphen (unless 

Yes, the hyphenation is embarassing still :^(


> Hyphenation rules works totally differently in french. As we said in
> _réflexions_, it's much simpler, and every kid in France knows them
> instinctively. To be frank, I couldn't state them 
> spontaneously, but I'm
> sure somebody here will do. XPress doesn't hyphen bad normally, but it

I can probably find these on the web, since it is "basic" information. I'd
rather talk about the issues of good layout that are not so easy to uncover.


> >6. in second to last line of paragraph
> >	=> because it sticks out if last line is not "full" and 
> looks bad
> 
> Rather to avoid last word hyphenated on last line, I think.

OK. I think an option to allow/disallow hyphenation of the last word of a
paragraph would do the same thing, and also prevent similar breaks falling
in the middle of the page.


> >p. 17, O. Randier
> >"...un petit éditeur de « metaglyph », qui permet de 
> composer son signe à
> >l'écran en mixant plusieurs..."
> >
> R. Keeble...
> >  This idea has been discussed in some circles in the 
> context of Japanese
> >publishing, where it is desirable to be able to combine 
<...>
> O. Randier...
> editor could be the base for math construction, and we don't 
> need to save
> all the equations of a math text as glyphs! So we should be 

Agreed. Is there enough reuse of formulas so that adding them to a library
would be useful?

> able to edit
> the metaglyph of, say, dotaccent-z, so as to change it 
> throughout a doc or
> to edit ponctually a metaglyph made once for a special use 
> (for example, a
> letter in a circle).

Interesting idea here about constructing glyphs that are not present in the
font, but do you mean accented forms, or other characters? I'm asking
because I haven't seen many fonts with accent glyphs (although Unicode will
change this), and more complex glyphs like cyrillic characters would be
tough to construct with some other font.


> >A. Hurtig
> >"...le réglage de la position des accents est presque impossible à
> >l'écran..."
> >
> >Q: Would this be easier (say if one were using a kern editor 
> of some sort
> >;^) if the kern pair, or n-ième set of glyphs was zoomed to 
> a much larger
> >scale?
> 
> Yes, but the point is that a glyph editor shouldn't work with kerning
> issues, IMHO (I think Alain would agree), because if you tune 
> the position
> of your accent with kerning as some tools do, all your work 
> may be ruined
> by a modification of the global tracking of the line :(

But dealing with this problem is required for Unicode, since it makes heavy
use of aggregate characters that are a base character with one or more
combining marks like accents. This creates a few requirements: 1) kerning in
both X and Y directions is needed because accents can "stack" when you have
more than one, and it would also be good for fine tuning positions; 2) the
application must treat these composed or aggregate characters as a single
glyph so accents and marks don't drift from their base character, as in
tracking; 3) kerning algorithms must be aware of these composed characters,
since the kerning of some character followed by just "e" may be different
than that character followed by "e" with a combining mark or accent. (There
are probably more convincing examples than this, but I'm only on my first
cup of coffee...I'm in timezone UTC-6 and France is UTC+1, non?)


> >- word space (cadratin?)
Someone pointed out that the word space is _not_ the same width as the
cadratin, but I thought I saw this confused somewhere in "Réflexions".


> In XPress, I usually set variable space to 25% in typographic 
> preferences
> to get correct thin space (I use to type variable space instead of
> non-breaking thin space as suggested in the handbook, because 
> the last one
> seems to be bugged). But I don't know what that 25% refers to 
> : em-space,
> en-space, figure space? That's not clear (should be). I would be very
> interested to know exactly how XPress does its calculation about that,
> because it seems there are issues between electronic and lead 
> type as to
> what really means an em-space.

I'll check. I can't remember off the top of my head, but I think the default
(=standard em-space not checked) is something nonsensical.


> There are tons of issues where kerning pairs don't work, especially in
> scientific typesetting. Examples :
> Chimical elements can have both exposants and indices on both sides,
> Y and ? can have both exposants and indices, that should be 
> at the same
> distance from the base element
> This is impossible to manage easily and automatically in 
> bounding box logic.

Ah, this isn't at all obvious if you haven't done sci/math typesetting. But
you would hope that a math layout engine would be clever enough to do this
automatically. I'm not a Tex user, but I'll M. Knuth gets it right -- it
sounds like basic math typography.


> Well, if you add the features we suggest, that should appear in Xtags,
> isn't it? So I think internal editing with a tool that have powerful
> wordprocessing capabilities especially in search/replace, 
> substitutions,
> macros and script language would suffice ;-)

I'll have to ponder what such an editor would look like...


Rob Keeble
Quark, Inc.