More comments on "Réflexions"

[Robert Keeble <RKeeble@xxxxxxxxx>]

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

3bis. (words beginning with cap) except when starting a phrase
	=> breaks the flow for the reader (?)

4. in combinant words (which already have a hyphen)
	=> looks really horrible if they break

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

6. in second to last line of paragraph
	=> because it sticks out if last line is not "full" and looks bad

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

======

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.

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?


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

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


Rob Keeble
Quark, Inc.