Re: [xep-support] Support of special types of spaces

From: Jim Melton <>
Date: Wed Oct 19 2005 - 16:08:43 PDT

As somebody with a long-abiding interest in computer typography (one
of my first real jobs was writing typesetting systems for
newspapers), I find myself agreeing in part with both sides of this debate.

I think I've settled on these points:

1) XEP hasn't done anything wrong with respect to its treatment of
spaces; the product is (as far as I know) conformant with XSL FL in
this regard.

2) David is right about the NBSP issue. But that is not the same
issue as is being discussed now. NBSP is merely a space whose
principal differentiating characteristic is that no line-break is
permitted to replace it.

3) There are genuine typographical uses for many of the other spaces
for which there are Unicode encodings, such as thin, hair, em, en,
etc. High-quality typography (e.g., text books, serious fiction,
etc.) depends on them.

4) I don't think that it particularly matters whether any given font
does or does not have the space character "in" the font. A rendering
engine can certainly compute the offset of subsequent characters
based on known (or presumed) characteristics of those spaces, which
are pretty well known (if not always absolutely rigid). That is, an
XSL FO engine can determine the "probable" width of a thin space
based on certain font characteristics, since type designers typically
start off with some assumptions and then fine-tune space widths by
eye anyway. A close approximation is almost always going to be quite
adequate if the actual space is missing from the font.

5) It is unreasonable to ask RenderX to jump off the pier and start
implementing new features based on ideas and comments on this list in
the absence of a broader discussion and, dare I say it, a
standard. In other words, I think that these comments about the need
for specific treatment of these space characters be directed to the
W3C's XSL Working Group in response to publication of XSL FO, which
was published as a Last Call Working Draft on 2005-07-28. Although
the comment period terminated on 2005-09-16, I'm sure that the group
would be interested in hearing comments and discussion on this subject.

Hope this helps,

At 10/19/2005 11:36 AM, David Tolpin wrote:
>>Again, its width is *supposed* to be font-dependent. Whether it's
>>in many fonts or not is irrelevant.
>But the original poster does not think so. The original poster
>advocates the approach that the typographical spaces should be
>computed if they are not in the font.
>>All XEP has to do is accept that several forms of space are fixed-
>>width, and thus should not be subject to variation due to
>>justification. The spaces can be inserted using entity names or
>>unicode character values.
>The previous space-related discussion was about NBSP. The discussion
>has been as emotional as this one, and the community stood strong
>behind the viewpoint that no-break white space should vary due to
>The only thing that can be done to make programs like XEP usable is
>to strongly discourage the use of typographical spaces until there is
>a clear and unambiguous specification of what to do with them. There
>are better means to accomplish good print quality; you don't have to
>use four-per-em and six-per-em to get a 5/12em white space these days.
>(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
>in the body of the message to from the address
>you are subscribed from.
>(*) By using the Service, you expressly agree to these Terms of

Jim Melton --- Editor of ISO/IEC 9075-* (SQL) Phone: +1.801.942.0144
   Co-Chair, W3C XML Query WG; F&O (etc.) editor Fax : +1.801.942.3345
Oracle Corporation Oracle Email: jim dot melton at oracle dot com
1930 Viscounti Drive Standards email: jim dot melton at acm dot org
Sandy, UT 84093-1063 USA Personal email: jim at melton dot name
= Facts are facts. But any opinions expressed are the opinions =
= only of myself and may or may not reflect the opinions of anybody =
= else with whom I may or may not have discussed the issues at hand. =

(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service
Received on Wed Oct 19 16:36:15 2005

This archive was generated by hypermail 2.1.8 : Wed Oct 19 2005 - 16:36:16 PDT