Re: Bug Report (reprise)

[Chris K <gnu...@li...>]

Ethan A Merritt wrote:
> On Wednesday 05 April 2006 02:24 am, Chris K wrote:
>>>> (The '/' character MUST be the first character after the '{'.)
>>> [the code] clearly skips spaces after each opening brace.
>>> So the "MUST" in the help and the code are in conflict.
> 
> I do not view this as a bug.
> 
> The docs state that the supported syntax is '{' followed immediately
> by '/'.  The code does support this.  It also forgives intervening
> whitespace, which is undocumented.  If you place extra whitespace
> in the command, then you have gone outside the documented spec and
> should not complain about the results. It happens that the code does
> something reasonable anyhow, which is a relatively user-friendly
> outcome and hardly deserves the label "bug".
> 

With only one parsing engine, then you get a consistent and implicitly defined
enhanced text specification.  The original Netscape browser made the decision to
be liberal in what it accepted and rendered, and so many people and programs
created nonstandard HTML and every other browser then had to deal with either
breaking backward compatibility with Netscape or copying the informal implicit
specification.  And upgrades to Netscape could not abandon the old leniency,
which is exactly what I am asking here: I want to make a clear decision on the
specification, document it, and make the parser match the documentation.

The only unclear clear bit of the enhanced text behavior and documentation has
to do with whitespace handling.  There are two goals to making a spec for this:

(1) It should be obvious to people which whitespace is significant so they can
add whitespace where they want it (i.e. principle of least surprise).
(2) It should be obvious to someone writing a GUI front-end how to write a
editor that generates enhanced text.

The secondary unclear bit of the current behavior is that the braces are not
always parsed in pair because of the localfontname parsing.