Rolled together replies to both e-mails. > Mark> I was unable to observe the problem with the currently deployed ON > Mark> Developer Reference. > > Yes, I cleaned it up with Emacs before posting it. If you want to see > the funny question-mark characters, you'll need to generate the old > version of the file, login to the site, edit one of the chapters, and > replace the current text with the text you generated. (Or I suppose I > could generate a screenshot...)
I downloaded the patch, that helped. > Mark> > http://cr.opensolaris.org/~kupfer/nbsp-fix/on-chunks/ch01.html.frames.html > Mark> > http://cr.opensolaris.org/~kupfer/nbsp-fix/on-chunks/ch01.html.udiff.html > [...] > Mark> - the change on 91 (and similar) is not clear to me, even from > Mark> viewing the page source from the udiffs > > I looked at ch01.html.udiff.html using XEmacs; it looks like webrev is > changing the 0240 in the old file to " ". I didn't understand this assertion. As viewed in an editor, the "old" lines still show the 0xa0 character. I checked webrev, and it doesn't do any encoding that would affect this. > The change at line 91 might be clearer if you download the patch file > and view it in your favorite text editor. For Emacs, move to the > "space" in > > title="Chapter 2. Prerequisites" > > and press C-x = . If I view the file using vi, I see a glyph resembling > a vertical bar after "Chapter" and after "2." in the old file, but not > in the new file. (I see this with both xterm and the GNOME terminal > emulator.) > > Mark> - I would have expected line 95 to show non-breaking spaces? Is > Mark> this just not getting the same treatment by xslt because it's a > Mark> different heading level? > > That's the only explanation I have. Ok. > Mark> Surely we're not finding a fundamental error in the docbook dtd? > > I don't know; I'm not a W3C standards lawyer. Most software seems able > to cope with 0xa0; this wouldn't be the first time we've run into a > problem with the current portal. "Indeed," on all counts. > Mark> Does my inability to reproduce the problem indicate a difference > Mark> in browser/font/environment/locale/etc? > > Ask me again if my previous email didn't help. It mostly helped. I guess that cr.opensolaris.org isn't part of the portal app, so the posted webrevs don't suffer from the same problems. > Mark> - If we DO keep the changes you propose: > Mark> -- the comments describing start_a() in fixup.py will need to > Mark> change > > Ah, yes. Will fix. Thanks. > Mark> -- why are the results of fix_href() applied conditionally, and > Mark> those from fix_title() unconditionally? (lines 163-168 in > Mark> fixup.py) > > No good reason. I don't know Python well enough to understand if there > are performance implications. I guess that unless there is a serious > performance hit from doing so, the cleanest approach would be to > unconditionally replace attributes[i] for both "href" and "title". I'll > do that unless you object. Making that change would be my inclination. --Mark
