public inbox for docbook-tools-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Alan W. Irwin" <irwin@beluga.phys.uvic.ca>
To: Norman Walsh <ndw@nwalsh.com>
Cc: docbook-tools-discuss@sourceware.cygnus.com
Subject: Re: blank line in lists
Date: Wed, 31 Oct 2001 07:19:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.40.0110310634160.23002-100000@starling.mylan.home> (raw)
In-Reply-To: <877ktcjazr.fsf@nwalsh.com>

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
>

  reply	other threads:[~2001-10-31  7:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 [this message]
2001-10-31  7:28     ` Norman Walsh
2001-10-31 14:44   ` Tammy Fox
     [not found] <Pine.LNX.4.40.0110261442550.28945-100000@starling.mylan.home>
     [not found] ` <1004124386.2147.279.camel@peecee>
2001-10-31  2:57   ` Norman Walsh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.40.0110310634160.23002-100000@starling.mylan.home \
    --to=irwin@beluga.phys.uvic.ca \
    --cc=docbook-tools-discuss@sourceware.cygnus.com \
    --cc=ndw@nwalsh.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).