[XP] Comments on _Réflexions_ so far

[Olivier RANDIER <orandier@xxxxxxxxxxx>]

J'ai rajouté d'office la balise [XP], puisque le débat semble s'engager, et
pour ne pas indisposer ceux que notre cuisine n'intéresse pas. Je vous
invite à faire de même désormais.

>» p.6 "Obliques are not italics"
>»  I wonder if the 'i' button should change to an oblique 'o' if a real
>» italic isn't available, and when the caret is in text with a new "oblique,
>» not italic" attribute?
>
>That may be confusing for (Sans) fonts whose italic identifies already
>itself as oblique... TeX has a name for that: slanted, which
>emphasizes pretty well the mechanical aspect of its
>generation. Moreover, some layouts use both italic & slanted (there is
>a theory according to which, as an `a' may be as well text as a math
>symbol, they should be distinguishable [i don't like that theory,
>though]). What about an extra `sl' button, and greying the `i' one
>when not available?

As I wrote in _Réflexions_, the main idea is to clearly distinguish between
fundamental typographic functions and graphic facilities. The italic
function must only refers to the italic (or oblique for Sans fonts) version
of the font.
If someone needs to slant the character, that should be distinct and,
usefully, adjustable.
In terms of interface, you could have an 'i' button, greyed when
italic/oblique isn't available, and another button which could be 'Sl' as
Thierry suggested, with a slanting value field. I could imagine the 'Sl'
icon shows a letter with an angle, like this :
|/Sl
Also, the way that 'i' button works isn't satisfactory. When you select a
text containing both roman and italic, then click on it, the text is
converted to full italic.
rrrrr iii rrrrr --> iiii iii iiii --> rrrr rrr rrrr
In typography, an italic text should become roman when the main text is
converted to italic.
rrrr iii rrrr --> iiii rrr iiii
On the contrary, in maths, italic and roman have a specific signification,
and we should be able to "lock" it, so as not to modify it accidentally
through global operation on the main text.
What I could imagine is a "lock" button that can be associated with every
style. Same for a "reversible" button.
Thinking of that, I would say that we could extend the principle of Boole
Algebra to all style operations. Something like PathFinder in Illustrator.
Am I clear?

>» p.7 Small caps
>» The idea of synthesizing these with multiple master fonts when *true* small
>» caps are not available is interesting, but how many people like and use MM
>» fonts?
>
>they're waiting for correct support in software!

Yes, you will read more about it in section I.1.g « Exploitation avancée
des Multiple Masters ». Note that we suggested that part of that support
could (should?) be assumed by the rasterization tool, i.e. ATM and the RIP.
As for small caps themselves, I'm still not sure that synthesizing is
really possible that way, there are issues regarding accents and serif
sizes matching with lower cases that could prevent from doing it that way.

>» essentially a virtual font that allows specifying harmonious "real"
>» fonts
>
>I think we discussed that issue somwhere at length, with TeX's VF as a
>guideline. This is a very _practical_ workaround as long as we don't
>have a huge collection of Unicode++ fonts (Unicode++ = Unicode + all
>typographer's glyphs like in adobe's glyph list
>http://www.adobe.com/supportservice/devrelations/typeforum/glyphlist.txt)

The more I think about that, the more I feel the need for an interface
between Unicode and fonts. What we need is a clear and efficient way to
link fonts between them and to parts of Unicode, or even to a single
character. We have fonts with Expert sets and so on, but not the tools to
use them. I mean that if I have an ffi ligature in a font, I should be able
to affect it to the ffi offset of Unicode, then use it the way I do it for
fi ligature, which is present in Mac standard encoding.
We don't really need Unicode fonts, fonts packed in an Unicode metafont
should work the same.
Of course, this is not necessarily a function of XPress, it could be
integrated in Suitcase or ATM/ATR (or in a new product, if you don't want
to be a one-software company anymore!).

One thing that bothered me once : it seems that XPress doesn't use standard
Quickdraw API for text styling. I once modified an SC font, affecting it
the Shadow attribute, so that when clicking on Shadow icon, I get SC text
easily. It worked in SimpleText, not in XPress! :(((

>» p.8 Superscript/subscript
>» It sounds like the conversation is mainly about typesetting formulas
>
>Not really. Having the ability to place arbitrary text at an arbitrary
>spot on the page (defined absolutely or relatively to current text
>flow) may be very handy for some works (avant-garde poetry,
>experimental typography). Our idea was that if there were kernel
>support for that, then a formula plug-in could be much more simple and
>integrated to the general interface.

One important point for me is to be able to ponctually escape to the logic
of one bouding box after another, the same way layout softwares escaped
from the line after another logic in word processors. We need that for
scientific composition, but also for specific typographic issues.

>» Regarding algorithmic kerning, I have to agree with F.H. Villebrod
>
>We all agree with him;-) The reading of the paper by P. Karow at
>RIDT'98 is usefull though (Jacques, c'est encore téléchargeable
>gratuitement chez Springer ?). The function as implemented in InDesign
>is half-satisfactory, so far...

Not all of us ;) I think algorithmic kerning may be possible, but needs
specific instructions within the font which doesn't exist for the moment.
The kerning enveloppes systems suggested in FontStudio doc is very
interesting, so as the kerning system in Calamus.

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