From: Jim Melton (firstname.lastname@example.org)
Date: Thu Apr 08 2004 - 10:43:30 PDT
I am, as always, delighted at the seriousness with which RenderX takes
input and suggestions from its users. Your company is definitely a leader
in understanding customer relations!
Because of my experience in a previous life writing typesetting systems, I
am sympathetic with the difficulty in discovering a mechanism for modifying
the way that hyphenation algorithms treat special cases (including special
characters). Thus, I really appreciate your willingness to think about how
this might be done in the context of XEP. Speaking personally, I think the
approach of identifying such modifications in terms of character classes is
likely to be a very successful approach. I am less certain about using the
specification of hyphenation patterns, probably because the systems on
which I have personally worked had very obscure mechanisms for specifying
those patterns ;^)
At 08:46 AM 4/8/2004 Thursday, Nikolai Grigoriev wrote:
>first of all, I'd like to thank you and all people who took part
>in the line-breaking discussion: it gives us important insights
>for future development.
>At Tuesday, April 06, 2004 8:13 PM, Jim Melton wrote:
> > I don't think that it would be a violation of your principles to allow
> > users to specify a list of "additional characters" at which words/strings
> > could be broken.
>We don't have any principles to disallow something :-). It is simply
>a matter of design: we are still in search of a proper interface to
>line breaking control.
> > It is *extremely* inconvenient for document authors to
> > have to manually insert zero-width spaces (no such think on *my* keyboard,
> > so I'd have to use a character entity reference) or soft hyphens (same
> > problem), especially when there might be literally scores or hundreds of
> > places in a large, dynamic document.
>You are not supposed to do it manually: stylesheets or other preprocessors
>should be able to cope with the task. Our initial assumption was that
>a user can implement a line breaking algorighm of whatever complexity
>by writing a separate preprocessor that would insert zero-width spaces
>and soft hyphens to control the formatter. Now it seems that the interface
>is too low-level, and requires too much effort to leverage.
> > I'd like to add my voice to Jim Quest's in asking that
> > RenderX reconsider the decisions regarding hyphenating/breaking
> > character sequences based on either predefined non-letter
> > characters or non-letter characters specified by the person
> > installing/configuring XEP, and the decision to arbitrarily
> > break character sequences when no such "break character"
> > can be found and no hyphenation rule can be applied.
>What we see from this thread is the need to add a configurable
>input preprocessor to XEP, so that line breaking could be expressed
>in terms of character classes and/or hyphenation patterns, rather than
>special characters. The work is about to start; I don't promise
>immediate results, but we are definitely going to take the issue
>(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
>in the body of the message to email@example.com from the address
>you are subscribed from.
>(*) By using the Service, you expressly agree to these Terms of Service
Jim Melton --- Editor of ISO/IEC 9075-* (SQL) Phone: +1.801.942.0144
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 Personal email: jim at melton dot name
USA Fax : +1.801.942.3345
= Facts are facts. However, 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 firstname.lastname@example.org from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html
This archive was generated by hypermail 2.1.5 : Thu Apr 08 2004 - 11:31:51 PDT