TADS Bug Database

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000178TADS 3Interpreterpublic2012-12-22 05:332013-04-25 03:26
Assigned ToMichael Roberts 
PlatformOSOS Version
Summary0000178: Nonconformant HTML tag: PRE
DescriptionThe TADS implementation is nonconformant and counterintuitive. TADS' "<PR
TagsNo tags attached.
Fixed In Version3.1.3
Attached Files

- Relationships

-  Notes
NRTurner (reporter)
2012-12-22 05:35
edited on: 2012-12-22 05:39

Description got truncated:
The TADS implementation is nonconformant and counterintuitive. TADS' "PRE" eats space destroying text formatting.

http://www.w3.org/community/webed/wiki/HTML/Elements/pre [^]

http://www.w3.org/TR/REC-html32#pre [^]

Preformatted Text

<!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)
2013-04-25 03:25
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.

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker