>>I guess the reason nobody thought <fo:br/> or <fo:newline/> would be
> >required is because a U+000A will do the trick.
> [ snip ]
>In any case, a linefeed (LF) must be honoured, and result in a linebreak.
>_If_ the conditions are right. What that means is, the initial value for
>"linefeed-treatment" is "treat-as-space", which _does_ do a conversion of
>U+000A to U+0020 (space). So you would want to specify
>"linefeed-treatment='preserve'" on an ancestor flow object (possibly
>fo:root) and allow it to propagate to the FOs of interest, as it is
>inheritable. The "whitespace-*" properties do not affect the linefeed, and
>suppress-at-line-break can also be left as it is.
>But essentially the LF is there to accomplish what you want to do. The
>initial setting of "linefeed-treatment" acts to give us LaTeX-like
>behaviour, but unlike LaTeX we can switch to something different in this
>regard, rather than use new markup.
The answer that you gave is also to be found a few lines down
from the first URL I gave you
4. Forced line-breaks are respected. Specifically, if A
is the glyph-area generated by a fo:character whose Unicode
character is U+000A, then A must be the last area in its
containing subset Si.
I don't mind admitting that as an outsider to the XML standard, this
looks like a bad, even a really bad, idea.
My reading of your commentary is "Whitespace is sometimes respected,
and only a langauge lawyer can tell you when".
How should this be interpreted?
Do you think that HTML would be improved if the <BR> element was
replaced with a feature that said "You can get the effect of a
forced linebreak by setting 'linefeed-treatment' to 'preserve'
in the <body> of the page (or other container as required), which
causes all unix line feeds to be rendered" instead the <br /> element
which is what was done?
>From my POV this has an inhibiting effect on all editors and pretty
printing utilities, which must also respect exisiting white space
(as XSL processors do) and never introduce line feeds, in case this
setting was ever turned on. From my POV, a formatter should always
ignore the formatting of the source, unless notified that it is
preformatted as in the case of <PRE> and CDATA, exempli gratia
(1994) about half way down.
Do you happen to know whether this was ever discussed (id est objections
sought and answered) or whether this was one person's idea that
was incorporated as is.
I have a related 'issue' which is that the normalize-string( ) function
in XSL does two things. It trims leading and trailling newlines
and other whitespace, and it normalises internal white space.
I have a need for an operation that does the former, but not the latter.
(In fact I have an implementation which appears to be buggy
and replaces 'Miss A Burgrave' with Miss ABurgrave', but handles
'Miss A Burgrave' correctly.
In short, XML processors including ones that produce XML-FO files
should pass through all whitespace, and processors such as fop
which are also XML processors, but adjusted so that they do not
produce XML, should (at least in general) normalise whitespace.
Where the output file format respects whitespace then it should
be supplied as <fo:text> or as some break (as my original suggestion)
The present situation is that the latter type of processor may not
normalise whitespace, because some newlines are significant.
Incidently, you have not made (or reported) a case against my suggestion:
unless it is harmful (or confusing) there is no real reason why both
styles of indicating significant breaks could not be used, is there?
Using FOP derived from version 0.14, I get this report when I tried
the following .fo
WARNING: property 'linefeed-treatment' ignored
WARNING: property 'linefeed-treatment' ignored
setting up fonts
formatting FOs into areas
rendering areas to PDF
<?xml version="1.0" encoding="UTF-8"?>
text-align="justified" font-size="12pt" font-family="serif"
<fo:region-body margin-bottom="50pt" />
<fo:region-after extent="25pt" />
<fo:page-sequence id="" hyphenate="true" master-name="all"
Westfarthing of the Shire.
line-feed treatment was reported as not working in June last
year, <URL: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1998 >,
I don't know whether tit is now in.
I now have a linux installation (but not yet CVS), and so I am in a position to
start some development work on FOP. Where should I start? Is there a list
of outstanding tasks?
I wrote that a few days ago, but delayed sending it until I could
see what bugzilla could tell me. In the meantime, bugzilla has sent
me an e-mail giving no fewer than 195 issues. My search on bugzilla
reveals 18 high priority bugs.
Nonetheless, my query remains, is there a list of issues which
people can start working on now, that won't need to be re-done
once the redesign is on place.
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]