On Mon, Nov 14, 2011 at 2:43 PM, Mike Maxwell <maxw...@umiacs.umd.edu> wrote: > On 11/14/2011 4:56 PM, Zdenek Wagner wrote:
> But in fact, the last time I tried this, the NBSP character was interpreted > in the same way as an ASCII space, which is not what I want. What I want > (repeating myself again) is for such characters to-- >>> have their Unicode-defined semantics, to the extent that >>> makes sense in XeTeX. > --just the same as I would expect XeTeX (or xdvipdfmx) to correctly handle > the visual re-ordering behavior of U+09C7 through U+09CC, or U+093F > (Devanagari vowel sign I). Would you be opposed to requiring an on-switch which would be required before unicode whitespace characters acquire special meaning? The nice thing about an on-switch is one can comment it out for debugging purposes. > >> However, I would not like to think, why I have >> overful/underful boxes and opening hex editor to see what kind of >> space is written between words. > > A number of alternatives to a hex editor have been pointed out: > 1) color coding Most color coding on text editors affects things other than whitespace. I think color coding whitespace will be visually problematic. > 2) using a font that has a representation of these code points Ok, so we'd have to use a spacial font to display things *instead of whitespace* > 3) using any text editor that allows you to see the Unicode code point of a > character (I use jEdit this way, I'm sure many other editors offer this > support) But you are still hunting here. > > Again, this is not about _forcing_ anyone to use NBSP etc., it is about > _allowing_ their use *with the expected Unicode behavior.* Hence my proposal to require enabling it as an optional feature, rather than making it the default behavior. Best Wishes, Chris Travers -------------------------------------------------- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
