Re: Authorship and formatting fixes on the versioning document I wrote

Laurence Rowe <[email protected]>
Newsgroups gmane.comp.web.zope.plone.documentation
Message-ID <[email protected]>
2010/2/14 Alexander Limi <limi-z4DKO/[email protected]>:
> (Adding in Laurence since this seems like it's part of the xdv setup or
> something in that chain :)
>
> On Sun, Feb 14, 2010 at 2:54 PM, Alexander Limi <limi-z4DKO/[email protected]> wrote:
>>
>> On Sun, Feb 14, 2010 at 1:02 PM, David Siedband <[email protected]>
>> wrote:
>>>
>>> the formatting on the code sections was somehow damaged in the move.
>>>  (All the code sections are now triple-spaced.)
>>
>> This is a bug in either the filtering algorithm or reStructuredText
>> combined with the conversion to HTML of this particular document, I believe.
>> My current suspicion is that we insert both CR and LF for a new line, and
>> that it's being shown differently in Firefox than WebKit (check out the
>> document in Safari, for instance).
>
> Yup, did some more investigation, and seems like this is the case.
>
> If you do:
> wget
> http://plone.org/documentation/manual/developer-manual/archetypes/appendix-practicals/enabling-versioning-on-your-custom-content-types
>
> …and then look at the source, you will see stuff like:
>
> <pre>&lt;?xml version="1.0"?&gt;&#13;
> &lt;object&gt;&#13;
>   &lt;difftypes&gt;&#13;
>
> Notice the &#13; at the end of every line, this is the code for Carriage
> Return as an HTML entity.
>
> Is it possible that this transformation happens as part of the xdv chain? If
> I do the same wget from the manage.plone.org setup, there's no &#13; to be
> found anywhere.

This looks like a serialisation artefact from libxml2. It seems that
Firefox and Webkit normalise newlines at different stages, with
Firefox performing the normalisation before the html is parsed and
Webkit only after parsing the html (and so converting &#13; to back to
CR).

>>> from urllib2 import urlopen
>>> doc = urlopen('http://manage.plone.org/documentation/manual/developer-manual/archetypes/appendix-practicals/enabling-versioning-on-your-custom-content-types').read()
>>> '\r' in doc
True
>>> doc = urlopen('http://plone.org/documentation/manual/developer-manual/archetypes/appendix-practicals/enabling-versioning-on-your-custom-content-types').read()
>>> '\r' in doc
False

The first CR character / entity reference actually turns up in the
description text area.

This affects all of our content as text areas have newlines
transferred as CRLF
(http://blogs.warwick.ac.uk/chrismay/entry/how_are_newlines/) and Zope
does no internal conversion from CRLF to LF. This means all user
entered content has CRLF line endings which gets included into the
page template output as is (the rest of the page template is rendered
with LF line endings). It's only a apparent in <pre> tags in FF after
the libxml2 parse / serialise.

I guess I can try to bring this up on the libxml2 mailing list.

Laurence

------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.