[xep-support] Support of special types of spaces

Jim Melton jim.melton at acm.org
Wed Oct 19 16:08:43 PDT 2005


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,
    Jim

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
>justification.
>
>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.
>
>David
>-------------------
>(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
>in the body of the message to majordomo at renderx.com from the address
>you are subscribed from.
>(*) By using the Service, you expressly agree to these Terms of 
>Service http://www.renderx.com/terms-of-service.html

========================================================================
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 majordomo at renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/terms-of-service.html



More information about the Xep-support mailing list