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

[Olivier RANDIER <orandier@xxxxxxxxxxx>]

>Salut,
>
>Continuing through "Réflexions"...
>
>p. 14-15
>  Several of the options for controlling hyphens I have not seen requested
>before, and I think I see the justification for them, so let me test my
>understanding of the reasons behind them:
>
>Hyphen control for...
>
>2. words in allcaps, regardless of whether they are caps by codepoint or
>attribute
>	=> hyphen breaks here may look bad

Yes, but we should be able to choose, globally and ponctually, and to
ensure that hyphenation works the same in both case (codepoint or
attribute) because we are not allways sure of the way it has been typed by
the author.

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

>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 specified by
user).
Same, I found a workaround with an optional hyphenation after or before the
hyphen, mais c'est ch... aussi, et ça marche même pas toujours ;(

>5. before silent final syllable [this is language specific]
>	=> this sounds similar to the anglo rule that bans breaking at
>points that make the pronunciation ambiguous

Not really. French doesn't allow hyphenation after "concupiscent"
(mnemotechnique for con- [cunt], cul- [ass], pis- [piss]) and a few others,
like -que* (queue [dick]), -chier [to shit], etc. The list should be very
short.
The silent final syllable is a different probleme, breaking before them
tends to force the reader to prononce too heavily syllables that are
suppose to be silent. The problem doesn't concern english where silent
syllables are very rare. This rule is not allways followed, but it's a kind
of politness for people which might have to read our texts loudly.
That is, if someone reads "italique", it sounds "italic" (same as in
english). If you hyphen, reader will probably pronounce "itali<breath>queu"
and the public could laugh :)
* This hyphenation is avoided with the silent final syllable rule.

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
could be better, especially when it comes to word roots. For example, I've
seen inte-raction instead of inter-action. The soft should first try to
hyphen between roots, i.e. try to hyphen auto-matique before automa-tique.
The list of roots should be enough short and, for the rest, an algoryhtme
should suffice where, AFAIK, XPress uses an hyphenation dictionnary (it's
useless in french).

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

>6bis. in last line of page, left or right
>	=> looks bad at bottom of page (Are separate controls for left and
>right needed here, or does the text specify that it should apply to
>Left/Right equally?)

Ideally, you should avoid breaking at the end of a page or collumn. In the
reality, better to avoid at least breaking before turning the page, i.e. at
the end of the right page. We need separate controls for left/right page
and collumns.

>======
>
>p. 17, O. Randier
>"...un petit éditeur de « metaglyph », qui permet de composer son signe à
>l'écran en mixant plusieurs..."
>
>  This idea has been discussed in some circles in the context of Japanese
>publishing, where it is desirable to be able to combine Kanji glyphs to
>construct proper names. But there are several useability issues: How should
>the user select the constructed glyph? Should it be saved as a new
>mini-font? Within the document, or outside, or both? How much glyph editing
>capability is enough? It pretty quickly seems like a capability that a
>separate, but nicely integrated application should provide.

I think the constructed glyph should select as a single character.
Double-clicking (or whatever is practical) on it should open the glyph
editor, to allow easy editing (in great size!). Constructed glyph could be
saved as metafont character when needed (very useful for some foreign
languages, like East European, if you don't have the corresponding font),
called by a macro. But it's not allways useful. I mean, in my idea, that
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 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).
As for the capability of the glyph editing, I think you should read
carefully the I.1.2 section of _Réflexions_, where we gave a good
lookaround. I know this concerns maths composition, but I think the glyph
editor could be a simple version (or a part) of it, with the same internal
engine.

>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 :(
That's one of the cases where we say you must escape the bounding box after
bounding box logic.
Glyphs in the glyph editor should place relatively to each other, that is
if I center a dot over a "z", the resulting glyph should behave as a single
character.
Also, with kerning issues, you get incorrect management of kerning pairs
because if you type az.u (. is for dotaccent), the second kerning pair is
between . and u, where it should be z-u. i.e. a dotaccent z should behave
mostly like a z for kerning pairs on the left and on the right. I think
that will be critical with optical kerning. Am I clear?

>p.19, C&Js/fixed width spaces
>  To sum up, it sounds like a larger selection of fixed width spaces is
>needed, and perhaps even with user control over the widths, as E. Curis
>points out on p. 22. Maybe something like
>
>- word space (cadratin?)
>- en-space (demi-cadratin)
>- fine space (4-per-em maybe, but controllable)
>- hair space
>
>  There are a few more listed at the end of the section like VeryThin,
>Medium, and Thick, and I wonder how many is sufficient, if the width is
>controlled by the user?

I think we need :
-- word space (as set in the font, of course it's not fixed width)
-- em-space (cadratin)
-- en-space (demi-cadratin)
-- figure space (for fonts where figures doesn't have a en-space width)
-- fine space (4-per-em maybe*, but controllable)
-- thin space (controllable)
-- user space (controllable, for special uses)
-- in english context, ponctuation space (same width as a dot or comma, if
I understand well)

Breaking or non-breaking should be an attribute for all of them.

* As for that, I still wonder : fine space is a space about half or 2/3 of
word space, that we all learnt as being a 1/4 em-space. But if I check
common fonts, word space is often 1/4 em-space, so thin space should better
be 1/8 em-space.
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.

>Would it also be useful to control the width of the
>"default" word space, say as m/2,m/3,m/4, and also as a percentage?

This is allready possible in C&J settings, but relatively to word space set
in the font (I hope?), but using fraction values or percentages of em-space
would be a plus.

>  It seems more flexible to have a non-breaking attribute, but would this be
>too much work for the user; inserting a special space, then marking it as
>non-breaking? On the other hand, keeping non-breaking spaces as distinct
>characters means remembering more keystrokes, or selecting from more choices
>on a dialog or menu...Search and replace support is clearly needed for these
>special spaces. What about style sheet support? How would meaningful support
>for style sheets behave, since these spaces are apparently used in special
>circumstances?

To type a non-breaking space, I add command key to spacekey. Non-breaking
attribute could work the same way.

>  As Thierry points out on p.20, as much automatin as possible is desireable
>-- so what other special cases exist besides an italic run followed by a
>close paren? (I wonder if there is an OpenType feature registered for
>something like this?)

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

>  I have noticed in much of "Réflexions" the idea that there should be a way
>to directly edit whatever is controlling the layout. Many GUI-oriented users
>would not like this type of interface because it is a bit like returning to
>a command line, but it seems something like this is needed to correct some
>layout problems. Since development time would be better spent on getting the
>layout right in the first place %^), what would a minimal markup language
>support? What is missing from XPress tags, besides direct editing
>capability?

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 ;-)

Is it possible that some form of GUI editing would be palatable
>to Math-heads, or will they always want that low level control, like us
>computer geeks?

No, most of the work should be feasable inside the GUI interface, low level
control should be useful only when you can't get what you want. We are not
geeks and I hate reading text in courier or geneva ;-(


Merci à tous de ne pas oublier la balise [XP].

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