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

[Olivier RANDIER <orandier@xxxxxxxxxxx>]

>> >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. [...].
>
>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.

Yes. Simply, allow breaking word with a cap after a final dot (dot, exclam,
question mark, ellipsis). There are issues about abreviating dots and some
others, but it should work most of the time.

>> >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 :^(

See also p. 15-16 about the possibility to use different glyphs for
hyphenation and combining words, when its needed.

>> 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!
>
>Agreed. Is there enough reuse of formulas so that adding them to a library
>would be useful?

I don't know but I don't think so. On the other hand, I guess a math editor
would rely on an internal library of common formulas. But it belongs to the
engine to manage with them, not to the user, I think.

>> 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.

I don't understand you there. In a standard Mac font, you have thirteen
isolated diacritics (acute, grave, circumflexe, dieresis, tilde, breve,
long, dotaccent, ring, cedilla, hungarhumlaut, ogonek, caron/hacek) plus
apostrophe and comma (used as diacritic in several languages), dotlessi
(used in turkish), dotcentered (used in catalan). They may not be
accessible with a standard keyboard resource, but you can get them easily
with PopChar. This should allow to create glyphs for almost any latin based
language, except, maybe, icelandic, polish and croatian. So a glyph editor
could allow us to typeset any latin-based language with any font even if it
doesn't exist in CE encoding or other. Of course it's better and simpler if
you can buy a specific font with high level kerning, but when you can't...
With flipping and rotating capacities in the glyph editor, we could be able
to create a great part of the glyphs for phonetic also (not all, but the
most common ones).
Cyrillic is, of course, a different problem. But I can imagine it's
possible to create glyphs for ancient greek from a modern greek font.
A glyph editor with vector drawing or import capacities would be great, of
course, but I suppose it could cause some difficulties, like compatibility
with ATM ripping, etc. But if you intend to extend XPress to font editor
capacities, none of us would complain! You could buy FontStudio from Adobe
to achieve its development towards OpenType, they don't seem to care about
it ;-)

>> 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.

I think Unicode as nothing to do with combining characters. As far as I
know, Unicode is not supposed to work this way. Combined characters are
supposed to be drawn specifically. The combination data included in Unicode
have only semantic meaning, i.e. an ffi lig must be understood as the
combination of three letters for obvious correcting and searching issues,
but the glyph is supposed to be a single character.
I doesn't mean we agree with that. For sure, the jonction between Unicode
support and a glyph editor capacities would be very interesting (see I.1.3
section).

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.

1) Yes, but, once again, kerning is not the good way to achieve this, IMHO.

Olivier RANDIER -- Experluette		mailto:orandier@xxxxxxxxxxx
	http://technopole.le-village.com/Experluette/index.html
Experluette : typographie et technologie de composition. L'Hypercasse
(projet de base de données typographique), l'Outil (ouvroir de typographie
illustrative).