langages scientifique, substitution automatique

[Robert Keeble <RKeeble@xxxxxxxxx>]

Bonjour a tous,

a question about pg. 41, M. Bovani comparing vertical bars for absolute
value:

"...doivent-ils être centré sur la ligne de base? L'expérience prouve que
c'est parfois oui parfois non..."

  Would a better default behavior be to ignore the baseline, scale these
symbols to the height of the expression or subexpression (eg. with nesting
braces), and allow for a stylistic "fudge factor", that allows adjusting the
default slightly larger or smaller? I might guess that for MathML, braces or
brackets applied to a subexpression manifest as markup tags surrounding the
expression, but I have not done any research on this yet.

  A few weeks ago, someone mentioned software that worked well for setting
Math? Are there other packages that anyone thinks do a good job in other
science fields? Is there anything for chemistry, etc?

---

Substitution automatique

p.44 les modificications stylistiques
Sure, it makes sense to apply styles and stylesheets to footnotes, tables,
etc. No debate there.

"...On prévoira un attribut spéciale et invisible : « Ne pas substituer » "

  If an application supported OpenType, many stylistic variations could be
supported as yes/no checkboxes, such as ligatures, discretionary ligatures,
etc. My question may need to wait for OpenType fonts to be common in the
marketplace, but I wonder if this level of control (turning OTF features on
or off on a text range) is enough? Will people usually want _all_ the
contextual substitutions in say, a discretionary ligature feature? Is it
sufficient to "turn off" a few undesired cases of substitution in a text run
with a "No substitution" attribute (or by applying a style with the feature
_not_ selected), or is finer control needed? Will people want to select
specific substitutions, case by case, from the available substitutions in
the font feature? (I think the later discussion gets to this a little)

p.45
  O. Randier notes that ligatures should be a character/text run attribute.
This sounds perfectly reasonable to me, but an example (why?) might be
useful.

  F.H. Villebrod mentions the idea that OpenType may ameliorate some issues
with spaces and justification, and I wonder what thoughts people have on
this. My reaction to the justification table of OpenType is that it will be
no more useful than a default H&J setting. Is it possible for a font
designer decide what justification parameters will work without ever seeing
the text of the document? Comments?

  Alain and Thierry point out a big headache on the horizon: what to do with
older fonts when (if) OpenType catches on? Many of the features in OpenType
would be difficult to simulate, although the virtual font idea combined with
multiple master support could at least automate things like small caps and
old style figures (elzévirien). Ligatures in expert fonts would probably
still be manual -- no automatic substitution without a table that maps sets
of characters to substitutions. But it would certainly be interesting (and
hard) to define a general, user controllable automatic substitution feature
as mentioned on p.48 that could do these sorts of things. I think this is
another feature that would be difficult to design a good user interface for.
Most users would understand simple substitutions where  xyz -> Q, but
wildcards or regular expressions would be too complex for many non-technical
users. Adding a rules layer would make it even more flexible, but again more
complicated for the average user. It's worth much more thought than I have
jotted down here. Anyone have an idea what sort of UI and capabilities might
be manageable for most users? I'll ponder this more over the weekend and
post something more cohesive.

---

(Changing fonts, some character is missing in new font)

  It *is* easy to see what characters are present in a font, but what should
the application do with this information: When the user changes the font to
MS-CoolGlyphs, should it compare which ligatures are present in each font
and tell the user which are missing? What if the missing ligatures aren't
even used? Should the application also check the document and only notify
the user which specific ligatures will be missed? It gets messy, cumbersome,
and slow rather fast.
  It seems more useful to have a tool that could build a profile of each
font and compare them in a way meaningful to the user -- ligatures present,
true smallcaps, whatever -- and can build a permanent database of the
information for future recall, for later comparisons, or for grouping fonts
in user-defined buckets as in ATR. I think  Apple's new FontSync even
proposes to go this far, even down to comparing at the glyph level. Has
anyone heard about this, and what do you think?


Have a good weekend if I don't hear from you before then.

Rob Keeble,
Quark, Inc.