Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000225Core InformExtensionspublic2010-08-01 09:252010-10-28 00:30
Assigned Tograham 
Platformx86OSMac OS XOS Version10.6
Product Version6E72 
Target VersionFixed in Version6F95 
Summary0000225: Spaces added to punctuation in extension documentation HTML
DescriptionSpaces are added around some punctuation. This can cause display issues, such as a list in a table displaying with the ending brace on a second row:

Table of Room Elements
sprite origin
Orthogonal_Room_Horizontal_1 { 63, 89
Orthogonal_Room_Round_1 { 87, 112

More importantly, it breaks URLS. Note the spaces after periods and colons:

http: //www. libpng. org/pub/png/pngintro. html

Minimal Source Text To Reproduce
New Extension by John Doe begins here.
New Extension ends here.

---- DOCUMENTATION ---- [^]
TagsNo tags attached.
Effect(cosmetic) Index is created incorrectly
Attached Files

- Relationships

-  Notes
EmacsUser (manager)
2010-08-02 08:14

I've confirmed the breaking of URLs and added source text to match. I haven't found source code that produces bad spacing around right curly braces though.
ektemple (reporter)
2010-08-04 16:51

Thanks. Maybe a better description of the curly brace thing: A space is added (and was in 5Z71 also) on the inside of all curly braces. The space is also pasted when using the paste button (or copying and pasting from the HTML documentation). So, a list of numbers that appears in the extension source like so:

{12, 12}


{ 12, 12 }
EmacsUser (manager)
2010-08-04 17:56
edited on: 2010-08-04 18:09

I'm afraid that's intended; to quote Graham in 0000048:0000024, ``Like most pretty-printers, cBlorb normalises the layout of what it prints; its job is not to reproduce exactly the layout in the source.''

The URL-breaking, on the other hand, is not just a matter of formatting preferences. {12, 12} carries the same meaning as { 12, 12 }, but ``'' [^] is rather different from ``http: //www. libpng. org/pub/png/pngintro. html.''

ektemple (reporter)
2010-08-04 18:28

That's fine, and the curly brackets aren't a very big deal, but I feel like I need to point out the following: The spacing of curly brackets can cause display problems with tables in extension documentation, whereas I don't think that non-spaced brackets would. So there doesn't seem to be much of an advantage to the insertion of spaces in the curly brace case. (It's also inconsistent--why space curly braces but not square brackets or parentheses?)
EmacsUser (manager)
2010-08-04 18:44

Yes, sorry, I forgot to account for you having said that in the issue description. What source are you using to provoke that behavior? I tried this (which I note is indented per the guidelines at the end of WI 25.10, despite Mantis adjusting the whitespace):

Table of Room Elements
sprite origin
Orthogonal_Room_Horizontal_1 {63, 89}
Orthogonal_Room_Round_1 {87, 112}
ektemple (reporter)
2010-08-04 18:49

Here's one (but there are several examples scattered through my documentation):

Table of Movable-Element Elements
movable-element origin image-ID display-layer display status x-scaling factor y-scaling factor associated room
PC Avatar {69, 95} Figure of Player Icon 5 g-active 0.4500 0.4500 Entrance Chamber

I trimmed some of the columns from my original report to improve legibility of the problem--I think it only happens when there are columns to the right of the column with braces.
EmacsUser (manager)
2010-08-04 19:14

Hmm. Using that code I can get the right curly to wrap independent of the last element, so it looks like what you describe when the documentation pane is appropriately sized, but not when I give the table sufficient screen real estate. Is that what you meant?
ektemple (reporter)
2010-08-04 19:19

Yes: basically, the table-column wrapping is fooled by the spaces into thinking that these are the braces and the numbers within are separate words, and so it breaks on them. The breaks, if they have to happen at all, should only happen on the comma+space, a "true" word break.
graham (administrator)
2010-09-29 11:45

I have improved Inform's handling of internal full stops and slashes, in such a way that most normal URLs will now pass cleanly through. (It remains the case that this is a pretty-printer, not a faithful file copy of the original text, though.)

- Issue History
Date Modified Username Field Change
2010-08-01 09:25 ektemple New Issue
2010-08-01 21:01 jmcgrew Status new => acknowledged
2010-08-02 08:14 EmacsUser Note Added: 0000367
2010-08-02 08:14 EmacsUser Reproducibility have not tried => always
2010-08-02 08:14 EmacsUser Status acknowledged => confirmed
2010-08-02 08:14 EmacsUser OS => Mac OS X
2010-08-02 08:14 EmacsUser OS Version => 10.6
2010-08-02 08:14 EmacsUser Platform => x86
2010-08-02 08:14 EmacsUser Steps to Reproduce Updated View Revisions
2010-08-04 16:51 ektemple Note Added: 0000369
2010-08-04 17:56 EmacsUser Note Added: 0000372
2010-08-04 18:09 EmacsUser Note Edited: 0000372 View Revisions
2010-08-04 18:28 ektemple Note Added: 0000373
2010-08-04 18:44 EmacsUser Note Added: 0000374
2010-08-04 18:49 ektemple Note Added: 0000375
2010-08-04 19:14 EmacsUser Note Added: 0000376
2010-08-04 19:19 ektemple Note Added: 0000377
2010-09-29 11:45 graham Note Added: 0000631
2010-09-29 11:45 graham Status confirmed => resolved
2010-09-29 11:45 graham Resolution open => fixed
2010-09-29 11:45 graham Assigned To => graham
2010-10-25 21:14 jmcgrew Fixed in Version => 6F95
2010-10-28 00:30 jmcgrew Status resolved => closed

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker