logilab-mtconverter #37276 [text2html] better line handling [resolved]
as of now,: a b will render as: a b since the converter concatenates lines why not apply the following:
diff --git a/transforms/__init__.py b/transforms/__init__.py
--- a/transforms/__init__.py
+++ b/transforms/__init__.py
@@ -83,7 +83,7 @@
if not res[-1].endswith('<p>'):
res.append('</p><p>')
else:
- res.append(xml_escape(line))
+ res.append(xml_escape(line) + '<br/>')
res.append('</p>')
return '\n'.join(res)
| |
| priority | normal |
|---|---|
| type | enhancement |
| done in | 0.8.2 |
| load | 0.100 |
| load left | 0.000 |
| closed by | <not specified> |
Comments
-
2010/08/04 08:37, written by acampeas
- what we can do with css
- use a <pre> tag (and there is a related ticket on this in the cubicweb forge)
- the role of <p> is to let the browser decide where to line jump and if we add <br>s it doesn't work any more
-
2010/08/04 08:45, written by acampeas
- css cannot guess when it is right to line feed if we remove the information from the transformed html
- we probably do not want to special case transform html output based on the input content format
- the role of <p> is to build paragraphs, the role of <br> is to force line feeds (they have different, but definitely not conflicting semantics)
-
2010/08/04 09:11, written by sthenault
-
2010/08/04 09:28, written by acampeas
-
2010/08/04 09:34
-
2010/08/04 09:45, written by sthenault
add commentarguments heard _against_:
I contend that none if this is relevant.
When a text snippet author puts a single n within his text, it is a semantic information that must be preserved. That we interpret nn as <p> is arguable (but acceptable), but I still fail to see one reason to not correctly encode single n.
Here is the point. '\n' is imo not a *semantinc* information. It's more usually
formatting information, and most often which has meaning *when you type the text* in.
Eg in the textarea, which doesn't behave like the final, html formatted, text.
Now the point is probably to make a compromise to get what *most* people expect
(eg, not necessarily me nor you). I tend to think people usually expect more
likely the behaviour you describe, not mine... Is there some people following
this story with an opinon on this ?
I disagree about 'n' not being a semantic information.
"A text file (sometimes spelled "textfile": an old alternate name is "flatfile") is a kind of computer file that is structured as a sequence of lines." says http://en.wikipedia.org/wiki/Text_file.
Please don't break our lines ...
The standard user using plain text format and not wanting to learn will be happy to use acampeas' solution, and is disappointed by the current solution. You cannot expect such users to adhere to emacs/vim conventions (sentences ending with dot space space, paragraphs ending with double LF, etc.). The closer you are in display to what the user was seeing when he typed his message, the better (think of cut and pasted stack traces from a terminal...)
The advanced user will use ReST and be happy with it.
The evil user will use HTML and do nasty stuff.
so be it then.
Though I still disagree this is *semantinc* :p