[K2]THE SYNTHESIS - part I.1

[Eric Muller <emuller@xxxxxxxxx>]

J'ai fait une premiere passe sur les 24 premieres pages. Pour l'instant,
j'utilise la premiere version publiee, ca serait sympa si quelqu'un pouvait
me donner toutes les modifs d'un coup, plus tard. En attendant la suite, je
vous propose de relire ca. Ca devrait divertir les lance flammes tout
chauds de sur Michel et Jacques, mais je m'en fout, j'ai mis ma veste en
amiante 8-).

Eric.




1 - Typography

1.1 Basic typographic features

1.1.a Style attributes

O. RANDIER - The logic of style attributes, which started with Apple's
Toolbox, has apparently reached its limits. To progress in
high-end typography, it is necessary to go beyond them. The main
defects: the binary character of many settings, and the limitations
of the current model.

Weight

The Bold attribute is not enough to handle font families with multiple
weights, like many are today. While one must certainly preserve the
bold/non-bold relationship, it would be useful to navigate the weights
by increments, via a keyboard shortcut and a slider, and to be able to
modify locally the weight called by the bold attribute.

Examples of attributes:
  <bold>
  <weight = 4/5>
  <bold, weight = +3>
  See also the "Advanced use of Multiple Masters" in this chapter.

Italic/Oblique

The Italic attribute is the source of numerous errors, because it
often allows the display of a synthetic italic (for fonts that do not
have a true italic), which is a violation of wysiwyg. It would be
useful that only actual fonts be displayed (this also applies to
bold). The italic function should be distinguished from the synthetic
italic function.

This would give two attributes:
  <italic>
  <obliqued, angle = x>

Outline

While this attribute is typographically bad, it has unfortunately
become necessary. Since it would difficult to make it disappear, it
may as well be handled correctly. Remember that the outside of the
line element should be tangent to the outline, and not its
centerline. It would be useful to control the thickness of this line
element, and it color could be defined independently of the that of
the letter, which could possibly be transparent.

 < outline, thickness=a, linecolor=b, lettercolor=c>

Note that the French translation of this attribute ("relief") is
absurd.

Shadow

Typographically as bad as the previous attribute. Unusable in the
current implementation, because it cannot be controlled. Graphic
designers use third party tools for complex shadows
(e.g. ShadowCaster), which generate bitmaps. It would be useful to
control directly the angle and distance of the shadow, as well as its
color and fuzziness. Those parameters should be recorded locally
(style) and the appropriate PostScript code should be generated.

  <shadow, angle=a, distance=b, fuzziness=c, letter-color=d,
   shadow-color=e,f>

Underline/Strikeout

The underline attribute relies on a simple PostScript function,
integrated in the font data, which is a thickness relative to the point
size and a distance to the baseline. The result is usually
ugly. It would be preferable (some XTensions do it more or less
correctly) to be able to specify thickness, distance to the baseline
and possibly color. In the later case, one should be able to specify
if the underline is before or after the letter! An important option it
to interrupt the underline each time it runs into the letter (a
descender, usually), and to specify the minimum clearance.

  <underline, distance=a, thickness=b, color=c, plane=front/back>

Underlined words and strikeout are marginal and can be considered
variations of the underline. Note that Underlined should not be an
attribute of the letters, but of the line, otherwise underlining text
with superscripts or subscripts is bound to create some surprises..

All caps

Nothing special to say on this attribute, other than it must
absolutely preserve accents (it usually is the case, fortunately),
unless the user specifies otherwise. In the case of other languages,
this attribute must handle correctly substitutions (e.g. <ss>=SS in
German). It is also necessary to handle correctly the difference
between "all caps" and change of case.

Small caps

Absolute disaster! This attribute, which did not exist in the ToolBox,
is an horrible kludge, which manipulates the point size and results in
incorrect relative weights. Two solutions:

- for fonts with an expert set, a logical link similar to the
regular/bold link should be used (modification of the Type1
format?). That would still leave some punctuation signs (apostrophe,
question mark, exclamation mark, etc) not necessarily handled in the
right font. A transformation by Unicode (see chapter I.3), similar to
what happens with All caps, would give an elegant solution, and keep
the distinction between local change and change of case.

- for Multiple Master fonts (see the section of MM), when true small
caps do not exist, they could be synthesized by controlling the weight
axis and the point size. The height of the small caps should then be
automatically computed from the lowercase bowls, unless the user
specifies otherwise.

Superscript/subscripts/superiors

Same problems as for small caps. Therefore the same solutions
apply*. In addition, for superscript and subscript, it should be noted
that their parameters (size reduction and vertical offset) leave room
to incorrect interpretation. For the superscript, XPress introduced an
improvement with the "Superieur" attribute, which has only a size
reduction parameter; the vertical offset is computed such that the
superscript is aligned on the capital bowl, which is typographically
correct. This could be extended to subscripts (alignment on
descenders). In the case of scientific publications, those
modifications should be cumulative (multiple layers of indices and
exponents), with an absolute limit to the point size modification. In
addition, those parameters should be local to the style sheet, not for
the whole document (as it is with XPress). Of course, one should be
able to specify those parameters either relative or absolute (point size).

*However, the Multiple Master solution is preferable, since it avoids
overloading Unicode with many case variations.


This closes the list of the current style attributes of the ToolBox,
but does not address those attributes which would be necessary to
handle more challenging typographic tasks, in particular for
scientific documents. We are not going to enumerate all the attributes
here (it would probably be impossible). We will come back to those in
section I.2.a.


b. Architecture of style attributes.

Let's mention that the attributes should be handled by an open
architecture, with a "programming" interface, to resolve specific
problems. This could allow more powerful parameters, such as:

- extension of a glyph on multiple lines (curly braces, integral sign,
etc).
- positioning relative to a glyph, a word or a selected expression
(simultaneous superscripts and subscripts, vectors, position of the
fraction bar wrt to the equal sign, etc)
- horizontal positioning
- rotation
- symmetry
- slanting
- ..

This implies that one is not always constrained by the linear logic of
bounding boxes aligned one after the other.

P. PICHAUREAU - I usually distinguish typographic and graphic
attributes. The distinction between the two is based on tradition.

Typographic attributes are the oldest  typographic modifications:
weight, italic, color, caps and small caps. The other are there
because we know how to do them, rather than because they are needed:
strikeout, underline, outline, transformations, etc.

Technically speaking, the first require a specific creation from the
font designer, while the second are often achieved by algorithmic
treatment of existing fonts. This distinction supports the
differentiation between the typographic domain and the graphic domain
(things done not in the text, but in titles, posters, etc.)

O.RANDIER - This is a good idea. I think one could, as you suggest,
distinguish in the document and also suggest the UI should distinguish,
to educate the users.

J-P. LACROUX - Ok, this is not really relevant for [K2], but here is
my point of view...

I believe this separation in two categories is too "typo...graphic"
and hides the most important: the written language.

 - the uppercase cannot be considered simple attributes or typographic
enrichments, because their most common use is syntactic and
orthographic (caps). The proof: this attribute is in principle handled
by good spell checkers and style checkers.

 - the use of italic, small caps, super- or subscripts is in part
codified and belongs to ??orthotypography. Some of those uses could be
handled by checkers.

 - the weight and color are purely typographic (which is not the case
of strikeout), as well as shadow, outlines or the various
transformations. Bold, which is often considered similar to italic is
in my mind much more similar to a change of point size, may be even a
change of font. The proof: there are multiple weights, while italic is
not (yet...) more or less italic, the caps more or less caps.

In short, a normal* text cannot exist without capitals, or it
become ??orthographiquement incorrect. It can exit without italic and
small caps, or superscripts, but it may then be
??othotypographiquement incorrect.. But it can always exist without
bold, underline, outline, shadow, color, etc.; none having any of
those will ever make it incorrect.

 *this does not include poems or scientific texts

To be more K2... I believe it would be educational for software to
stop the confusion and that they should clearly separate (in menus,
dialog boxes, etc) those three classes. Up to now, the confusion was
amusing. With the new technologies (MM), it could turn to a
disaster. Hence the necessity of separating that which is not only
graphic...



d. Kerning

O. RANDIER. - Today, kerning relies on a very simple model, that of
kerning pairs. Those are recorded in the font and must be created by
the font designer, a work often tedious and painful, and therefore
kept to the bare minimum. If necessary pairs are missing, the
typesetter can add them, but this is rarely done. The main limitation
of this model is that it falls apart as soon as two characters of
different fonts are juxtaposed, or even when two different point sizes
are used (sub- and superscripts).

Calamus offers a different system. Its fonts have, in addition to
the bounding box, a finer decomposition of the space occupied by a
character in rectangles. Then, the layout software does the kerning,
by adjusting the space between characters such that those rectangles
mesh better.

Similarly, FontStudio supports the creation of kern tables from rough
vector descriptions of the letter shapes; the same description can
also be used to compute the character width and the side bearings.

While the actual font market does not offer such a functionality, we
believe that such a system would correctly handle problems which are
bound to increase with multi-lingual composition. Therefore, in
addition to the actual system, an algorithmic computation would be
nice. The power of today's machines opens the door to more
computational methods.

  <we should have here a description of the different systems>

T. BOUCHE - What comes out of the recent discussion is that the method
inherited from hot metal (average bearings + possible modifications) is
itself a limitation outside of the average case. The question could
be: why not forget the bearings and just position each character
intelligently depending on its position in the word, the line,...

O. RANDIER - In the case of a software that does the right thing,
yes. But we should not forget that fonts are not made only for use in
high-end software. The bearings are generally set to give a correct
result, even in software that does not use kerning pairs.

In my mind, there are three levels in the use of fonts:

 - bounding boxes simply adjacent, for the simple software at $2
  (SimpleText).

 - bounding boxes + kerning pairs for the next level of sophistication

 - outlines + software positioning for high-end

F.H. VILLEBROD - Quite right, and it is concrete for the first two
levels, which is the essence of the actual situation. But for the
software positioning, we will have to wait another generation of AI,
when one will not need - may be unfortunately - the typograph to
smooth the layout!

[...]

The positioning using outlines is still limited. The outline must
be created by the designer anyway, and does not assure that all
possible pairs will be correctly positioned.

The eye - but more importantly the brain behind it - carries out a
complex computation without the typesetter realizing it himself. The
difficulty is easily measured when taking the result of manual work:
no simple geometric rule (to maintain a distance between outlines, for
example) can be found to explain the result.

A comparative modification of the white and black areas occurs at the
interface between two characters, but it does not take into account
just a single measure, but rather many. Subjective and esthetic
criteria also come into play. Just try to formalize that procedure and
to implement it!

To increase the quality of kerning in high-end publishing, let's stay
practical. I think that it would be better to ask for a better
handling of pairs, including pairs with space (I complained recently
to Quark about this) and even of triplets and quadruplets*, as well as
some simplifications such as the grouping of characters with identical
lateral outlines in classes*.

  *this is done in the OpenType format.

A tool to edit pairs must be able to use the text that is being set
(with a zoom to 1000% rather than just 400%) to store the kerning
modifications done by the typesetter as he works. The new kern data
must not only travel with the document, it must also be possible to
extract it in an AFM file to use it later in a font editing
software. This amounts to handling kerning similarly to spelling and
hyphenation exceptions.

One should even be allowed to record kerning for specific point
sizes, since kerning of text and kerning of titles are different.

The ultimate solution would allow to move the glyph within its
bounding box. Would we then also need a dictionary of bearings
associated to the kerning dictionary? It gets complex, but why not?


g. Advance use of Multiple Masters

O. RANDIER - Most typesetters agree that Multiple Master fonts have
been a major improvement of font formats, in particular because they
allowed optical correction in desktop publishing. Unfortunately, those
functions are not used currently, and the implementation of MM is
usually prohibitive. A modern page layout software cannot ignore them
and must totally support them, which implies an interactive use and
not a preset use (I first create instances and then I typeset). When
using an MM font, the software* should be able to create appropriate
instances on the fly, to modify them and to recreate them whenever
necessary.

 * It is not necessary that the software be the piece that does all
this. In fact, it would be preferable that the rasterizer (ATM or
Display PostScript for display, PostScript for printing) handle that,
so that this function could be used in other contexts.

For example, the decrease or increase of the point size should lead to
the creation or modification of the instances used in the composition
of the selected text. Similarly, for a width variation. And for
weight, in addition to the scale mentioned in section I.1.a, one
should be able to create intermediary weights, by entering a
percentage, for example.

This is the bare minimum for MM fonts. Let's now look at more advance
uses of MM fonts. In fact, one could argue that MM could be the
solution to handle families without an expert set and the absence of
glyphic variants in Unicode.

Small caps/sub-/superscripts

It is possible to generate typographically correct small caps by
computing an instance based on the height of the bowls of the lower
case and on their weight. Similarly for super- and subscripts.

Scientific typesetting

Typesetting of scientific texts calls for notations that could be
efficiently handled by the creation of appropriate MM instances. Let's
mention: curly braces, brackets, square roots, which encompass a
variable number of lines but must keep the same absolute weight, the
notations for angles or vectors, which use signs that are "stretched"
over or under expressions, etc.

T. BOUCHE - It should be possible to disengage these automatic
behaviors. For example, if I want to create a special effect using 6
optical points for Minion in a title. That being said, playing with
the name may be enough. In the current system, when you use Minion in
6 points, it is the default instance that is scaled to 6 points. It
seems obvious to me that it should be the version 6 <<optical?>>
points that should be used. Still in today's system, you can use
MinionMM_345wd_555wt_6op as any other unimaster, therefore in the
point size of your choice, as long as you created the instance in ATM
_beforehand_. It seems to me that both systems can coexist.

O. RANDIER - I totally agree. The idea is that by default, un
??enrichissement
causes the appropriate instance to be used, except if the user
specifies otherwise. But it seems to me that it's important that the
creation of instance be more important, otherwise, why bother?
Incidentally, I
intended to write something about a fair number of automatic behaviors that

could be disabled, that could be very educational, such as limiting
by amount much the width can be reduced (for example, a novice
cannot reduce the width by more than 10%, and if he insists, an alert
asks for confirmation).


e. H&J

A. HURTIG - It not the scope of this work to handle hyphenation
completely, there are many other erudite works. Also, it not in the
scope to speak of other languages than French: however, there would
certainly a lot to say about other languages.

It is simply to register our dissatisfaction: hyphenation is not good,
and that in none of the commercial software. To the point where for
XPress, specialized plug-ins have been developed for various
languages.

  Is it acceptable to have to pay extra to get a software that handles
correctly hyphenation in French?

  Is it acceptable to have to pay even more to hyphenate correctly in
different languages?

  Is it acceptable to have to spend hours to fix manually incorrect
hyphenation?

But is seems that the common rules of hyphenation in French are known
by the software vendors (most of the prohibited hyphenations seems to
be correctly handled, for example). So what's going on?

First, most of the packages have only three parameters of hyphenation:

1. minimum length of words to hyphenate, minimum number of letters
before and after the hyphen (this influences the typographic color).

2. hyphenation allowed or prohibited for words starting with an
uppercase.

3. number of consecutive hyphenations.

In the case of French hyphenation, and without considering the
interaction with justification algorithms (which will be handled
later), the parameters should cover the following cases:

1. minimum length of words to hyphenate, minimum number of letters
before and after the hyphen.

1a. number of consecutive hyphenations.

2. hyphenation of words all in uppercase - obviously including
uppercase entered as such and uppercase that is part of the
style. (yes/no)

3. hyphenation of words starting with an uppercase (yes/no)

3a. except if they start a sentence (therefore following a period or
and end of paragraph. (yes/no)

4. in composite words (hyphenation necessarily on the dash, or
necessarily outside the dash) (yes/no)

5. hyphenation before a final syllable (yes/no) (for me, it's no!)

6. hyphenation on the line before the last line of a paragraph (yes/no)

6a and 6b. on the last line of a page, of a right-hand page, of a
left-hand page (yes/no).


A. LA BONTE - I have complained about this problem with American
software on French text for years. In English, one must imperatively
use a dictionary, while in French, everything can be done by an
algorithm. Every little French pupil knows where to hyphenate...this
is not the case for English speakers, the rules are more numerous, so
much so that it's mandatory for Joe-Six-Pack to use a dictionary
(every good English dictionary shows where it is possible to
hyphenate). It's what the American software does... but when the word
is not in the dictionary, they approximate, most of the time with bad
results in French [...].

For once, French is easier to handle, the complexity of the original
software has not been reduced (poor localization and poor design for
localization).

It would be worth to document the rules exhaustively. Grevisse [[one of
the references for French grammar]] does it, but he does not include
exceptions (a number of which are optional if one interprets
liberally what Grevisse says), most notably the most important, the
mandatory, i.e. the list of non breakable digraphs.

J.P. LACROUX - In some cases (teaching material), I advise the use of
a special sign [...].

- reference works on language. If it is sound to give a single name to
a graphic sign, it remains that a single sign cannot be used
unambiguously for two "different" meanings. This is sometime
bothersome in teaching material. Let's take again the example of
sous-[marin. The hyphenation occurring after the first element,
nothing indicate to the reader attempting to learn french that this
word does not spell [sousmarin]. Conversely, the same reader, when
confronted with the hyphenation anti[brouillard > anti-brouillard, may
believe that the dash is necessary after the anti prefix and with
always write [anti-brouillard]...

[...]Girault-Duvivier understood that well when he used two different
signs in his Grammar of grammars ("-" for dash, "=" for hyphen)[...].

Composite words (and occasionally joined words: "dit-il") must preserve
the graphic integrity of their dashes; it is for ordinary hyphenations
that one should use a sign distinct for the dash [...] A slanted dash
could be just fine. (If this convention is used, one will not be able
to use fonts where the dash is slanted...)

G. PERES - in the Webster, two signs are indeed used to distinguish
hyphenation: dash for hyphenations that do not coincide with a dash,
and some kind of slanted = to indicate that there is normally a dash
at this position.

J.P. LACROUX - yes, but I find the Webster deficient in the same way
as the Lexique du francais pratique... Using two signs is a very good
idea, but the dash should be reserved to the case where the words
contains a hyphen. I prefer the opposite (that of Girault-Duvivier):
  sous-
  marin
  anti= (or ??, or better, because simpler, the slanted dash
  brouillard

e. H&J - special spaces

A. HURTIG - [...]There are some special characters with are necessary
for typography.

Right now, I am thinking about non justifying spaces, generally absent
from software packages (XPress has one, equal to the 1/2em, I
believe).

Let's ask for three non justifying spaces, with widths of a word
space, a half-em and a hairspace.

T. BOUCHE - Do you see non-justifying or not? or is it a separate
attribute?

A. HURTIG - are there other typographic characters we need?

T. BOUCHE - beginning and end of word or line? TeX has a compound word
mark, that is inserted between the two parts of a compound word in
German, which allows to hyphenate correctly (without hyphen?).

Ligatures also play a role, which depend a lot on the coding or the
ability of the software to interact with fonts (ability to create on
the fly ligatures between two characters, if the AFM contains an L
instruction, for example), therefore to adapt itself to fonts that
have many ligatures, for example.

J.D. RONDINET - with:
- a non-breaking hairspace 1/4em
- a non-breaking justifying space
- a breaking justifying space
I could typeset text in all cases iI know (general, newspapers, books).

The hairspace (or any other small hairspace) would be
welcome, since it would allow the use of search-and-replace some
problems where we currently use a change of spacing.

T. BOUCHE - if this is really a problem (such as missing f<`e>
kerning, or wrong T<"y> kerning), then I believe it's better to be
able to modify in the layout software and save a new AFM? But it's
true that I did this kind of thing.

J.D. RONDINET - no, I was thinking about problems such as

                       1
    ... comme on l'a vu dans mon rapport

[["1" is a superscript on "vu"]]
The 1/4em is a bit too wide to separate the
superscript "1". Same thing if a superscript or a regular closing
paren follows a word in italic, there is sometimes collision... These
problems are not universal and are particular to some fonts, therefore
must be seen and can be handled by a search-and-replace.

T. BOUCHE - In the ideal system we are discussing, the knowledge of
the glyphs outlines should allow the correct placement of superscripts
and should handle italic correction... But let's not fall in the trap
of sending the problem to software engineering and not take care of it
ourselves... Yes, I think that an hair space (let's say 1/2 pt or 1/20
em should be fine) is useful, but then I also want a negative one!

E. CURIS - How is that different from inserting manually a bearing?

J.D. RONDINET - the search-and-replace! Very important!

E. CURIS - I don't buy it: you can also do search-and-replace if the
software is properly designed. Not very sophisticated (i.e. no
"replace all the bearings smaller than 1 pt by bearings of 1pt",
but it's the same with spaces, so), but it's a good start: nothing
prevents to support "search for f<`e> and replace it by f[space of x%
em]<`e>".

So my question still stands, other than with a side-bearing, one can
also modify the vertical position but not so with a space.

J.D. RONDINET - if this command is available in K2, I have no reason
to complain.

But know says it will be there, or that it will be asked? This concept
exists in no software package...except yours. This will not be a
selling point for Adobe?

So..a bird in the hand is better than two in the bush!

T. BOUCHE - it's not so much that the bearings are wrong in the
case of a superscript, but rather than the notion of bearing is not
relevant to that case. My take in that discussion is that we should
ask for as many automatic behaviors as possible, it's simpler for us,
but we should always be able to correct manually.

J. ANDRE - That's also my opinion, and I believe this is the main
difference between adepts of the full wysiwig and those more used to
the old batch tools.

A. HURTIG - I don't see any problem. It's quite possible to have a
full wysiwig package, but to also be able to access the guts of the
document, using a metalanguage, for example.

XPress already does it somewhat, using tags for all the typographic
data, that can then be corrected manually (that applies only to the
text and possibly to anchored images, and many things such as the
position of text blocks in the page and their size are not handled -
that being said, it's helpful).

J. ANDRE - I meant the opposite: if you have an automated tool (which
is not always perfect), you also need wysiwig to make local
modifications.

A. HURTIG - I don't understand... "local modifications"? But I want to
see my whole page, not just a part. And I want to see all the pages
and modify them at the screen in real time.

J. ANDRE - But I believe it's still better to have first an automated
tool that does most of the work.

A. HURTIG - I understand even less. There is necessarily an "automated
tool that does most of the work".

Wysiwyg is an additional layer, both for rendering (see what you do,
without having to visualize it mentally first) and for production
(move a bloc with the mouse, modify a vector, all that stuff...)

T. BOUCHE - Yes, the wysiwyg we are speaking about right now, because
often, one can do only what one sees, with simple-minded
wysiwyg. That's why we are speaking about optional automated
behaviors, and about finer control than what's possible at 72 dpi
with a mouse.

A. HURTIG - Users of TeX (I say that nicely), I sometime wonder on
which planet you are. Not in one where you have to make a 500 pages
book in less than a week, not in one where a page of advertising is
done in less that a day, not in one where a 600 pages catalog is done
in less than a month.

J. ANDRE - But we do! I just typesetted 660 pages of conference
proceedings full of math and figures in less than a month.

I don't want to participate in the wysiwyg vs. batch war! I am the
first to regret the lack of interactivity of TeX and friends. But for
me wysiwyg does not mean "additional layer", but something like the
old PageMaker where everything could be done with the mouse; but
where everything had to be done by hand.

For a month a good tool is one that does 99% of the work automatically
(it's not to me to put the fi ligatures in the right places) and that
also allows me to correct with the mouse or manually the 1% where I
need to fix something.

A. HURTIG - It's nice, the lack of graphic interface, of Display
PostScript (or Display anything, I don't care), of display and
interaction in real time. But sorry, it is a lunacy out of the norm.

Thierry Bouche recently alluded to the typesetter group of the IN
[[Imprimerie Nationale]] which handles the examinations. This guys
tried many systems: Compugraphics, plug-ins for XPress, separate
software, almost everything. I spoke with them 2 years ago. The only
solution they forcefully ruled out was to come back to a textual
interface and to the programming of the mathematic formulas and
non-latin characters. "We don't have the time! We process hundreds of
formulas every day, it's a factory here." [...]

T. BOUCHE - Jacques Andre already answered you. TeX is a production
system, companies like Elsevier (the biggest scientific publisher)
have large teams of LaTeX engineers and of typesetters trained to
TeX. It's true that most documents are prepared by the authors, and
since they use the same tool, it's not possible to remove their
mistakes by an import filter (by the way, that's also a subject for
K2, no?: import filter from text processing system that removes all
the typographic marks [but not the orthographic signs]). For a
magazine such as the one published by my Institute, with well-trained
typesetters, it takes less than half a day to make an article. Modern
TeX systems are fun too: commands are in color, you can enter
everything with keyboard shortcuts or via pop-up menus. Preview also
happens practically in real time. Don't think about us as old timers
straining their eyes on b&w 12" screens, having to flash 100 pages
before discovering a stupid mistake. Where TeX shows its age, it's on
the page layout functions. The best for me would be to leave the
micro-typography to a program such as TeX or hz or nts or ... and the
wysiwyg interface for the page layout. For example, I will answer on
math later, but in math, the spacing of the letter f depends on its
use: as a function, a relation; a coma can represent a punctuation
(textual), a mathematical punctuation (interval [a, b]) or a decimal
separator (1,2). How can you, in wysiwyg, distinguish those uses?

So, as it has already been said: wysiwyg interface, with underlying
tagged language, which can be edited directly, or access by dialog box
to modify such and such parameter at such and such location. Once this
architecture is in place, I believe the development of plug-ins is
much easier and therefore not all functionality needs to be available
in the box.

E. CURIS - And if we follow that path, isn't a single space for which one
can specify the width more powerful? And for the programmers, it
must be simpler (let's think about them :-). Assuming that we also
have shortcuts to get this space with this or that width, so the user
is happy too.

T. BOUCHE - Yes, that's an implementation detail. For me, adding this
space means typing \kern-.1ex, so a more user-friendly method would be
welcome.

J.D. RONDINET - While I think about it: let's be careful that the
codes for these spaces can be typed in a search-and-replace dialog (no
Apple-space or Ctrl-something!), may be as simple as something obscure
(\f) or a code ($111)...

PS: What's the value (and relative to what?) of a word space in XP and
others? and that of punctuation space? The user's manuals are not very
helpful there...

T. BOUCHE - it depends on the font. In usual point sizes, it's more or
less the width of an "i". It should decrease at bigger point sizes,
but increase in the smaller ones. In general, the stretching is taken
care of by the software, as in "AFM value +/- x%". It's often about a
1/4 em.

J.D. RONDINET - subsidiary question, but applying to all spaces: in
all the actual book fonts, do the digits always have a 1/2em width?
This is important if we ask of K2 to correctly handle tables.

T. BOUCHE - We have already discussed this, I think it will sometime
show up in the FAQ, there are multiple digits available nowadays:
uppercase - usually with a fixed width, but not always, Adobe provides
a onefitted with a smaller width that preserves the typographic color
in titles - which is about the same width as an N; lowercase - usually
also with a constant width, contrary to popular thinking - which are
often provided with kerning that allows harmonious use in text (but
there, it's the common problem of bearing at the end of "words");
there is also, but less common (e.g. Bell) small cap digits
(i.e. aligned on small caps) which support this (incorrectly good?)
Anglo-saxon idea that small caps are a mean to do capitals that are
not too visible...

O. RANDIER - small caps digits are very useful to create fractions: if
you have a font with exponent and small cap digits, you only need the
fraction bar (and not the slash, as I remarked somewhere else) to
typeset all fractions. With a good kerning, it works by itself and
avoids the necessity of non-sensical fraction fonts.

T. BOUCHE - I am not sure we are speaking about the same thing. In
expert sets, there are digits which I forgot from my list because they
where not relevant for the original problem: the inferiors and
superiors, the first smaller than the bowl, the second more or less
aligned on the caps. There are indeed acceptable for fractions or for
super-/subscripts, but a little bit small to be used in text body or
in table. What I was referring to, under the label small cap digits,
are those you find in MT Bell Expert (instead of the lower case ones)
which are (geo)metrically to upper case digits what small caps are to
caps. The Americans (at least some of them, including Hudson) call
them short digits.

T. BOUCHE - The system with fixed width + kerning is simpler to get
something coherent in text, and good alignment in table: you just
ignore kerning in tables.

O. RANDIER - Except that for the system we are thinking about, it
would be the opposite: you kern and ignore width everywhere, except in
tables. Which make the one-fitted useless.

T. BOUCHE - For text, the best is of course lowercase digits of
proportional width (+ kerning in some cases such as 74, and kerning with
space, period 7., ...).

For titles in caps, the best is caps digits of proportional width.

For tables, in general, lowercase digits with fixed width and no
kerning.

In some other cases, such as ??appel de notes, mathematical exponents,
lowercase digits are often weird, but the others are not very well
adapted  and not very legible.

I take this opportunity to push by case: Unicode distinguishes caps and
lowercase (well, caps and small ... letters), many forms of asterisk,
but no capital digits nor lowercase digits! This is stupid, it makes
using both in the same document very difficult, which is quite
necessary if there is a title in caps, or if the layout software
supports cut-and-paste.

O. RANDIER - In fact, it's much worse. In Unicode, there are capital
digits, exponent digits, small cap digits, everything but lowercase
digits (unless, in their mind, small caps are lowercase...)! Which
brings us back to the old discussion on the distinction between glyph
and character in Unicode. If there are small cap digits, it does not
make sense not to have letters as well. And, after all, all those
digits are only different glyphs of a same character.

T. BOUCHE - Unless the correct solution relies on many fonts selected
based on the context?

T. BOUCHE - On that thread, I'll mention the MathML standard
<http://www.w3.org/TR/PR-math/toc.hmtl>. On spaces, here is the plan
(you can see that Unicode does handle some of those, which names that
are very glyph-oriented, with MathML uses much more reasonable names.

Entity name        Unicode Description
&Tab;              X09     tabulator stop
&NewLine;          X10 force a line break
&IndentingNewLine; -  force a line break and indent appropriately on next
line
&NoBreak;          - never break line here
&GoodBreak;        - if a linebreak is needed, here is a good spot
&BadBreak;         - if a linebreak is needed, try to avoid breaking here
&Space;            0020 one em of space in the current font
&NonBreakingSpace; 00A0 space that is not a legal breakpoint
&ZeroWidthSpace;   200B space of no width at all
&VeryThinSpace;    2009 space of width 1/18 em
&ThinSpace;        2006 space of width 3/18 em
&MediumSpace;      2005 space of width 4/18 em
&ThickSpace;       2004 space of width 5/18 em
&NegativeVeryThinSpace; - space of width -1/18 em
&NegativeThinSpace; - space of width -3/18 em
&NegativeMediumSpace; - space of width -4/18 em
&NegativeThickSpace; - space of width -5/18 em
&InvisibleComma; - used as a separator, e.g., in indices
(Section 3.2.4)
&InvisibleTimes; - marks multiplication when it is understood
without a mark (Section 3.2.4)
&ApplyFunction; - character showing function application in
presentation tagging (Section 3.2.4)

(- = not in Unicode)



e) H&J - natural flow of text.

A. HURTIG - A page layout that was common in the press earlier (and
sometimes in books) is to use two columns and titles on only one, this
column being of the width of the two others.

Not clear? Then here it is:

    TITLE-TITLE
    1111  1111
    1111  1111
    1111  1111

You will object that it still exists. Not really. You can find titles,
or citation in large characters not justified and strapping multiple
columns, but the text flow almost never follows the natural path,
which would be to stay nicely under the relevant title:


    TITLE-TITLE
    1111  1111
    1111  1111
    1111  1111
    TITLE-TITLE
    2222  2222
    2222  2222
    2222  2222

Instead you can see this ugly mess:


    TITLE-TITLE
    1111  2222
    1111  2222
    1111  2222
    TITLE-TITLE
    1111  2222
    1111  2222
    1111  2222

And this for a very simple reason: the natural path of the flow is
terribly difficult to set up.

In any case, in XPress, where the number of columns is an attribute of
the block that contains the whole text, and not an attribute of the
text itself, it a royal pain. Of course: any correction, increasing or
decreasing the 1111 part moves the 2222 part and everything needs to
be laid out again!

The solution could be that columns and justification be attributes
of the text (in the style sheet, for example) and not of the box that
contains it. The box determines the justification (horizontal and
vertical), but it's the style of the text that indicates how to use
it...

This method would allow a better handling of any element that is not
part of the flow of the main text, such as imported images, tables,
and more.

In fact, it may already exist (I saw an old typesetting system that
worked that way, but I don't remember it's name), maybe on Calamus.

e) H&J - overflow of text

J.D. RONDINET - [...] removal of the "small square with a cross" for
texts that are too long, for a much less visible sign.

<p25>