|Anonymous | Login||2018-06-19 21:31 EDT|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000178||TADS 3||Interpreter||public||2012-12-22 05:33||2013-04-25 03:26|
|Assigned To||Michael Roberts|
|Summary||0000178: Nonconformant HTML tag: PRE|
|Description||The TADS implementation is nonconformant and counterintuitive. TADS' "<PR|
|Tags||No tags attached.|
|Fixed In Version||3.1.3|
edited on: 2012-12-22 05:39
Description got truncated:
The TADS implementation is nonconformant and counterintuitive. TADS' "PRE" eats space destroying text formatting.
<!ELEMENT PRE - - (%text)* -(%pre.exclusion)>
width NUMBER #implied
The PRE element can be used to include preformatted text. User agents render this in a fixed pitch font, preserving spacing associated with white space characters such as space and newline characters. Automatic word-wrap should be disabled within PRE elements.
Note that the SGML standard requires that the parser remove a newline immediately following the start tag or immediately preceding the end tag.
PRE has the same content model as paragraphs, excluding images and elements that produce changes in font size, e.g. IMG, BIG, SMALL, SUB, SUP and FONT.
A few user agents support the WIDTH attribute. It provides a hint to the user agent of the required width in characters. The user agent can use this to select an appropriate font size or to indent the content appropriately.
Here is an example of a PRE element; a verse from Shelley (To a Skylark):
Higher still and higher From the earth thou springest Like a cloud of fire; The blue deep thou wingest, And singing still dost soar, and soaring ever singest.
which is rendered as:
Higher still and higher
From the earth thou springest
Like a cloud of fire;
The blue deep thou wingest,
And singing still dost soar, and soaring ever singest.
The horizontal tab character (encoded in Unicode, US ASCII and ISO 8859-1 as decimal 9) should be interpreted as the smallest non-zero number of spaces which will leave the number of characters so far on the line as a multiple of 8. Its use is strongly discouraged since it is common practice when editing to set the tab-spacing to other values, leading to misaligned documents.
Michael Roberts (administrator)
edited on: 2013-04-25 03:26
What's going on here is a little complicated. The HTML layer actually handles whitespace in PRE sections correctly, but the output formatter in the VM filters spaces before they ever make it to the HTML layer. The VM formatter collapses each run of whitespace into a single space, which is where your indentation and alignment spacing is getting lost. You can work around this in the current version by using quoted space characters - "\ " sequences (backslash-space). The VM formatter passes those through to the HTML layer without any filtering, and the HTML layer will then display them properly in a PRE section. You can use String.findReplace() to substitute "\ " sequences for regular spaces, so that you don't have to write the strings that way (which would be really hard to read for long runs of spaces for alignment purposes).
For the next update, I've improved the VM formatter so that it's aware of PRE sections, and when a PRE section is in effect, it passes whitespace and newlines through to the HTML layer unchanged. This makes it PRE work mostly as you'd expect.
There is one remaining complication, which is the way the compiler treats line breaks within strings. The compiler replaces each line break within a string, along with all of the indentation on the next line, with a single space. This means that you can't write multi-line PRE sections quite as plainly as in regular HTML, because the line breaks in the source file aren't preserved as line breaks in the strings, and they also lose the next line's indentation. The way to deal with this is to put an explicit \n (newline) at the start of each line in the PRE section. The compiler doesn't treat the \n as a whitespace character for the purposes of removing indentation, so the whitespace after the \n at the start of each line will be retained. In 3.1.3, I've also modified the compiler's handling of strings so that you can get the same effect by putting a \n at the *end* of each line in a multi-line string; when a line ends with \n, the compiler keeps the indentation at the start of the next line as part of the string rather than deleting it. This is essentially equivalent to starting each line with \n, so this doesn't really add any functionality you can't get now, but I think it's somewhat clearer to be able to write the \n's at the ends of lines.
|2012-12-22 05:33||NRTurner||New Issue|
|2012-12-22 05:35||NRTurner||Note Added: 0000294|
|2012-12-22 05:37||NRTurner||Note Edited: 0000294|
|2012-12-22 05:38||NRTurner||Note Edited: 0000294|
|2012-12-22 05:39||NRTurner||Note Edited: 0000294|
|2012-12-22 05:39||NRTurner||Note Edited: 0000294|
|2013-04-25 03:25||Michael Roberts||Fixed In Version||=> 3.1.3|
|2013-04-25 03:25||Michael Roberts||Note Added: 0000338|
|2013-04-25 03:25||Michael Roberts||Status||new => resolved|
|2013-04-25 03:25||Michael Roberts||Resolution||open => fixed|
|2013-04-25 03:25||Michael Roberts||Assigned To||=> Michael Roberts|
|2013-04-25 03:26||Michael Roberts||Note Edited: 0000338||View Revisions|
|Copyright © 2000 - 2018 MantisBT Team|