public inbox for docbook-tools-discuss@sourceware.org
 help / color / mirror / Atom feed
* Re: blank line in lists
       [not found] ` <1004124386.2147.279.camel@peecee>
@ 2001-10-31  2:57   ` Norman Walsh
  0 siblings, 0 replies; 5+ messages in thread
From: Norman Walsh @ 2001-10-31  2:57 UTC (permalink / raw)
  To: Gregory Leblanc; +Cc: docbook-tools-discuss

/ Gregory Leblanc <gleblanc@linuxweasel.com> was heard to say:
| as well, things will be a bit more consistent.  Norm never did reply to
| Peter's second message, but if you're interested in more info,
| docbook-apps is a much better list than this one (people actually
| post/read that list more than once every other month).

Hmm. Peter's second message included a patch that I haven't had time
to evaluate yet. (I knew there had to be a reason I hadn't replied :-)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Every new beginning comes from some
http://nwalsh.com/            | other beginning's end.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: blank line in lists
  2001-10-31  3:38 ` Norman Walsh
  2001-10-31  7:19   ` Alan W. Irwin
@ 2001-10-31 14:44   ` Tammy Fox
  1 sibling, 0 replies; 5+ messages in thread
From: Tammy Fox @ 2001-10-31 14:44 UTC (permalink / raw)
  To: docbook-tools-discuss; +Cc: Norman Walsh

On Wed, Oct 31, 2001 at 06:38:00AM -0500, Norman Walsh wrote:
> / "Alan W. Irwin" <irwin@beluga.phys.uvic.ca> was heard to say:
> | Is he saying in a mixed content environment (I presume lists are examples of
> | that) that no filling or justification of paragraphs is done?  That is what
> | would happen if white space were preserved.  Of course, "preserved" is a
> | stronger statement than "significant" so I guess what I really need is
> | a definition of significant.
> | 
> | Would Norm or some other expert here be willing to expand on the remark?
> 
> "Significant" in this case means "passed through to the application". So,
> if you say:
> 
> <para>
> Some text</para>
> 
> What the application sees is "Begin a paragraph" "Newline" "Some text"
> "End a paragraph".
> 
> So if the application thinks newlines are significant in paragraphs,
> you get an extra newline.
> 
> What's really odd though is that I can't reproduce this problem
> without the intervening indexterm. And I expect the intervening
> indexterm is just a backend bug.
> 
> (What are you generating? TeX, RTF, HTML, ... ?)
> 

I am trying to generate PS and PDF when I see this problem. 
The HTML output looks fine because it ignores whitespace.

Tammy

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: blank line in lists
  2001-10-31  7:19   ` Alan W. Irwin
@ 2001-10-31  7:28     ` Norman Walsh
  0 siblings, 0 replies; 5+ messages in thread
From: Norman Walsh @ 2001-10-31  7:28 UTC (permalink / raw)
  To: Alan W. Irwin; +Cc: docbook-tools-discuss

/ "Alan W. Irwin" <irwin@beluga.phys.uvic.ca> was heard to say:
| Let's concentrate on the jade html backend although I suspect the problem
| occurs for all jade backends.  To verify the problem I suggest you try jade
| with html output, and you should see that propagated nl *looking directly at
| the raw html file result* at the start of paragraphs in mixed environments
| like lists.

Yes, I know what the markup looks like, but...

| because the browser interpretation of that leading nl in the HTML varies
| between browsers. As I recall mozilla ignored it while netscape 4.7 and
| konqueror paid attention to it leading to the problem that the original
| poster was discussing.

Netscape 6.2 seems to ignore the leading whitespace, which I think is the
correct behavior for HTML.

| Concentrating on the html here, if the html standards say leading nl's in
| paragraphs are valid in the context of lists or other mixed environments
| then it is up to the individual browser to ignore them, and obviously the
| problem is not jade's fault.

That, I believe, is the case.

| However, if the html standards say leading
| nl's for paragraphs within lists are invalid, then this is jade's problem
| which should be fixed.  In case of doubt about the html standards, I
| understand there are validators which should make it easy to tell whether
| the jade html output is valid for the leading nl situation we have been
| discussing.

There's no question of validity or not, a newline can occur anywhere
in a <p>.  But what the browsers are supposed to do may be an open
question.

There are a class of problems that arise because things are allowed in
DocBook that are not allowed in HTML (lists inside paragraphs for
one). They are not easy to fix in Jade. In practice, I generally heave my
generated HTML through tidy. It's a hack, but it usually helps. Except where
tidy %@%!W@$@#s up, of course :-(

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | In the life of saints, technically so
http://nwalsh.com/            | called, the spiritual facilities are
                              | strong, but what gives the impression
                              | of extravagance proves usually on
                              | examination to be a relative deficiency
                              | of intellect.--William James

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: blank line in lists
  2001-10-31  3:38 ` Norman Walsh
@ 2001-10-31  7:19   ` Alan W. Irwin
  2001-10-31  7:28     ` Norman Walsh
  2001-10-31 14:44   ` Tammy Fox
  1 sibling, 1 reply; 5+ messages in thread
From: Alan W. Irwin @ 2001-10-31  7:19 UTC (permalink / raw)
  To: Norman Walsh; +Cc: docbook-tools-discuss

Thanks, Norman, for that clear definition.

The original poster had a good example of the problem.  But I responded
because I have often run into that problem myself.  I worked around it by
being very careful of leading nl's in my DocBook-XML source paragraphs in a
mixed content environment, but I always thought of it as a bug that needed
to be fixed.  It's been 6 months since I have looked at this so the rest of
my post is based on my memory of what went on then.  So I may have some of
the details wrong.  But I proved to my satisfaction at that time that jade
propagated the nl at the start of paragraphs in mixed environments.  I
don't think it does this for paragraphs in more ordinary environments, but
I am not sure.

Let's concentrate on the jade html backend although I suspect the problem
occurs for all jade backends.  To verify the problem I suggest you try jade
with html output, and you should see that propagated nl *looking directly at
the raw html file result* at the start of paragraphs in mixed environments
like lists. In other words the generated html varys depending on whether
that leading nl is in the docbook source or not.  Then things get murky,
because the browser interpretation of that leading nl in the HTML varies
between browsers. As I recall mozilla ignored it while netscape 4.7 and
konqueror paid attention to it leading to the problem that the original
poster was discussing.

Concentrating on the html here, if the html standards say leading nl's in
paragraphs are valid in the context of lists or other mixed environments
then it is up to the individual browser to ignore them, and obviously the
problem is not jade's fault.  However, if the html standards say leading
nl's for paragraphs within lists are invalid, then this is jade's problem
which should be fixed.  In case of doubt about the html standards, I
understand there are validators which should make it easy to tell whether
the jade html output is valid for the leading nl situation we have been
discussing.

Hope this helps to clarify the problem.

Alan

email: irwin@beluga.phys.uvic.ca
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On 31 Oct 2001, Norman Walsh wrote:

> / "Alan W. Irwin" <irwin@beluga.phys.uvic.ca> was heard to say:
> | Is he saying in a mixed content environment (I presume lists are examples of
> | that) that no filling or justification of paragraphs is done?  That is what
> | would happen if white space were preserved.  Of course, "preserved" is a
> | stronger statement than "significant" so I guess what I really need is
> | a definition of significant.
> |
> | Would Norm or some other expert here be willing to expand on the remark?
>
> "Significant" in this case means "passed through to the application". So,
> if you say:
>
> <para>
> Some text</para>
>
> What the application sees is "Begin a paragraph" "Newline" "Some text"
> "End a paragraph".
>
> So if the application thinks newlines are significant in paragraphs,
> you get an extra newline.
>
> What's really odd though is that I can't reproduce this problem
> without the intervening indexterm. And I expect the intervening
> indexterm is just a backend bug.
>
> (What are you generating? TeX, RTF, HTML, ... ?)
>
>                                         Be seeing you,
>                                           norm
>
> --
> Norman Walsh <ndw@nwalsh.com> | "Abstraction, abstraction and
> http://nwalsh.com/            | abstraction." This is the answer to the
>                               | question, "What are the three most
>                               | important words in programming?"--Paul
>                               | Hudak
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: blank line in lists
       [not found] <Pine.LNX.4.40.0110261601400.28945-100000@starling.mylan.home>
@ 2001-10-31  3:38 ` Norman Walsh
  2001-10-31  7:19   ` Alan W. Irwin
  2001-10-31 14:44   ` Tammy Fox
  0 siblings, 2 replies; 5+ messages in thread
From: Norman Walsh @ 2001-10-31  3:38 UTC (permalink / raw)
  To: Alan W. Irwin; +Cc: docbook-tools-discuss

/ "Alan W. Irwin" <irwin@beluga.phys.uvic.ca> was heard to say:
| Is he saying in a mixed content environment (I presume lists are examples of
| that) that no filling or justification of paragraphs is done?  That is what
| would happen if white space were preserved.  Of course, "preserved" is a
| stronger statement than "significant" so I guess what I really need is
| a definition of significant.
| 
| Would Norm or some other expert here be willing to expand on the remark?

"Significant" in this case means "passed through to the application". So,
if you say:

<para>
Some text</para>

What the application sees is "Begin a paragraph" "Newline" "Some text"
"End a paragraph".

So if the application thinks newlines are significant in paragraphs,
you get an extra newline.

What's really odd though is that I can't reproduce this problem
without the intervening indexterm. And I expect the intervening
indexterm is just a backend bug.

(What are you generating? TeX, RTF, HTML, ... ?)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | "Abstraction, abstraction and
http://nwalsh.com/            | abstraction." This is the answer to the
                              | question, "What are the three most
                              | important words in programming?"--Paul
                              | Hudak

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2001-10-31 14:44 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <Pine.LNX.4.40.0110261442550.28945-100000@starling.mylan.home>
     [not found] ` <1004124386.2147.279.camel@peecee>
2001-10-31  2:57   ` blank line in lists Norman Walsh
     [not found] <Pine.LNX.4.40.0110261601400.28945-100000@starling.mylan.home>
2001-10-31  3:38 ` Norman Walsh
2001-10-31  7:19   ` Alan W. Irwin
2001-10-31  7:28     ` Norman Walsh
2001-10-31 14:44   ` Tammy Fox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).