Re: [Docutils-users] Re: rendering ellipsis_

[David G. <go...@py...>]

[Felix Wiemann]
 > For example, normal dash, en-dash and em-dash are hardly
 > distinguishable in a monospaced font.  And a 'true' ellipsis would
 > be rendered much too narrow in monospace.

Yes, there are limitations when using/requiring monospace typefaces.

 > And even if it's possible to enter such characters, it is not
 > intuitive.

I hope it's becoming more possible and intuitive though.  Perhaps I've
been spoiled, being used to the easy non-ASCII input methods that Macs
have had since the beginning.  I'm now setting up a Debian system
which will be my main desktop; I'll find out the current situation
there.

 > and if they were told to enter unicode-symbols, they would find it
 > extremely inconvenient (I do, too).

I think that's a failing of the operating systems people use.  The
world is moving toward internationalization, with Unicode and UTF-8 at
the forefront.  I hope it gets here soon so we can ignore the issue
completely.

 > In fact, it's very natural to write en-dashes as two normal dashes
 > -- like this.  Or maybe also em-dashes---like this.  And you'd
 > always write ellipses like this...  Or like this ...

You illustrate a problem: there is no one standard for such
transformations.  And there's no way to distinguish between
"transformation desired" and "leave as-is" in normal text.

Such ambiguity is the reason why I decided to ignore the issue.  It's
a "refuse the temptation to guess" situation.

 > The LaTeX writer already does the en-/em-dash transformation
 > (because LaTeX automatically transforms '--' into a real en-dash and
 > the LaTeX writer doesn't escape dashes), and I have been using them
 > and found them quite convenient.

I question whether the LaTeX writer *should* be doing this.  At the
least it should be an option, disabled by default.

 > However, sometimes this behavior is undesired, e.g. when typing
 > options, like --stylesheet (without surrounding ``literal quotes``).

Exactly.

 > An intelligent replacement mechanism in the reStructuredText parser
 > would fix this problem, because it could transform "foo -- bar", but
 > not "foo--bar" nor " --bar".  And "foo---bar", but not "foo --- bar"
 > (I think), and also not "-----" (sometimes people might use such
 > repeated dashes e.g. to render arrows).
 >
 > Such an intelligent mechanism would greatly simplify inputting
 > reStructuredText.

Again, any such system should be optional, and disabled by default.

 > So I propose the following:
 >
 > * Add intelligent en-dash and em-dash transformation to the reST
 >   parser.
 > * Add intelligent ellipsis transformation to the LaTeX writer.

You may be opening up a big can of worms.  Once the underlying system
is there, won't there be a bunch of requests for (potentially
conflicting) additions?  When will it stop?

 > | If this is not possible in an authoring environment, a
 > | pre-processing stage can be added,
 >
 > Not really.  A pre- or post-processor cannot distinguish between
 > literal (= monospaced) and normal text, just to name one problem.

That's true.

 > I don't see any disadvantages in adding an automatic transformation.

I do, because it won't do what I want 100% of the time.  It has to be
optional.

-- 
David Goodger <http://python.net/~goodger>