"Arved Sandstrom" <Arved_37@nnnn> wrote:
> I think the predominant opinion is (assume all of this fits on one page) -
> 
> a normal block area (generated by the outer block) that contains:
> 
> one or more line areas for "level_0_text fills to position A";
> then a block area with one or more line areas for "level_1_text positioned
> at A fills to position B";
> finally more line areas for "more level_0_text positioned at B".
> 
> Note that if your example had been
> 
> <fo:block>
>         level_0_text fills to position A<fo:block>
>                 level_1_text positioned at A fills to position B
>         </fo:block>more level_0_text positioned at B
> </fo:block>
> 
> then it would still be the same.

As a side note, assuming western language and script and hyphenation
off, if the example had been

 <fo:block>
         level_0_text fills to position
          A<fo:block>level_1_text positioned at A fills to position B
         </fo:block>more level_0_text positioned at B
 </fo:block>

it is probably illegal, according to 4.7.2, Point 3. I suppose
it would be illegal to have a line break within the word
 "Alevel_1_text"
here. The problem here is, where do I get the rules whether a line
break is permitted somewhere for a certain language and script? And
how is this supposed to deal with "out of context" stuff like product
numbers or artificial DB keys or programming language identifiers
containing underlines and dashes, and with non-breaking spaces, odd
symbols, and character abuse (uppercase greek omega instead of Ohm
sign)? Again, I suppose the burden has to be put on the user who
has to ensure everything is correct, including changing the current
language for quotes, nested if necessary, and specifying a language
for product numbers and programming language ids. Umm, something
looking like
  ..., ISBN <fo:inline language="x-isbn">0-201-48345-9</fo:inline>...
and
  the <fo:inline language="x-Java">org.apache.fop.render.pdf.Font<fo:inline>
 class implements the <fo:inline
  language="x-Java">org.apache.fop.layout.FontMetric<fo:inline>
 interface ...

This would eleminate some keep-together stuff, I guess, but most
probably requires a mechanism to teach the processor line breaking
rules for user defined languages.

<DumbQuestions>
- Is the interpretation reasonable? (I don't ask about correctness...:-)
- Can the redesigned FOP deal with the "Alevel_1_text" above, I mean
  will it raise an error or warning?
- Can/should FOP deal with user supplied word/line breaking rules?
</DumbQuestions>

Note that the same applies to the recently heavily discussed problem
of a block level element inside an fo:inline, according to 4.7.3, in
particular point 3.

J.Pietschmann

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to