[Plone-docs] Authorship and formatting fixes on the versioning document I wrote

[David Siedband]

I was pleased to see a document that I wrote had made it into the
developers manual:

http://plone.org/documentation/manual/developer-manual/archetypes/appendix-practicals/enabling-versioning-on-your-custom-content-types

Unfortunately, the authorship information has been changed to indicate
that Mikko wrote this, and the formatting on the code sections was
somehow damaged in the move. (All the code sections are now triple-
spaced.)

How do we go about getting these issues fixed?

Thanks,
--
David Siedband
http://zentraal.com

[Alexander Limi]

Post by David Siedband
I was pleased to see a document that I wrote had made it into the
http://plone.org/documentation/manual/developer-manual/archetypes/appendix-practicals/enabling-versioning-on-your-custom-content-types
Unfortunately, the authorship information has been changed to indicate that
Mikko wrote this

It should be possible to adjust this in the Ownership section on the Edit
page, but I notice that it isn't exposed by default. Probably something we
should fix.

In any case, there won't be any ownership displayed very prominently in the
manuals, to encourage community ownership of those parts. The knowledge base
articles will be more person-centric, since they are more standalone units.

And let me know if this feels wrong, it seemed like there was agreement on
this when it was discussed a while back, but maybe some people disagree.

Post by David Siedband
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).

I fixed the triple linebreaks, so now it's normal, but unfortunately still
looks double in FF. I'll ask some people at work about it.

[Alexander Limi]

(Adding in Laurence since this seems like it's part of the xdv setup or
something in that chain :)

Post by Alexander Limi

Post by David Siedband
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.

[Laurence Rowe]

Post by Alexander Limi
(Adding in Laurence since this seems like it's part of the xdv setup or
something in that chain :)

Post by Alexander Limi

Post by David Siedband
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.
wget
http://plone.org/documentation/manual/developer-manual/archetypes/appendix-practicals/enabling-versioning-on-your-custom-content-types
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).

Post by Alexander Limi

Post by Alexander Limi

Post by David Siedband
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

Post by Alexander Limi

Post by Alexander Limi

Post by David Siedband
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

[Alexander Limi]

Post by Laurence Rowe
This looks like a serialisation artefact from libxml2.

Yeah, I assumed it would be something like that. :)

Post by Laurence Rowe
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.

Great, thank you for doing this. If it can't be fixed there, we need some
sort of filter on the Zope side to filter out CRs, is that correct?

[Laurence Rowe]

Post by Alexander Limi

Post by Laurence Rowe
This looks like a serialisation artefact from libxml2.

Yeah, I assumed it would be something like that. :)

Post by Laurence Rowe
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.

Great, thank you for doing this. If it can't be fixed there, we need some
sort of filter on the Zope side to filter out CRs, is that correct?

Scratch that. I just realised I can do a string replacement on text
within a <pre> to remove the CR chars.

Laurence

[Alexander Limi]

Post by Laurence Rowe
Scratch that. I just realised I can do a string replacement on text
within a <pre> to remove the CR chars.

Ah, nice. And we're running "your" stack on plone.org now, right? So this is
something we could have fixed in reasonable time, I assume? (ie. we don't
have to wait for a new release of libxml, etc)

[Laurence Rowe]

Post by Alexander Limi

Post by Laurence Rowe
Scratch that. I just realised I can do a string replacement on text
within a <pre> to remove the CR chars.

Ah, nice. And we're running "your" stack on plone.org now, right? So this is
something we could have fixed in reasonable time, I assume? (ie. we don't
have to wait for a new release of libxml, etc)

I've added the following to default-extra.xsl, run buildout to update
the compiled xsl, reloaded nginx and cleared the varnish cache.

| <xsl:template match="pre/text()"
xmlns:str="http://exslt.org/strings" mode="initial-stage">
| <xsl:value-of select="str:replace(., '&#13;', '')"/>
| </xsl:template>

Those pesky CR are now gone and it looks fine in Firefox.

Laurence