DO NOT REPLY [Bug 36977] - [PATCH]TextLayoutManager CJK line break

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36977





--- Additional Comments From [EMAIL PROTECTED]  2005-10-11 07:24 ---
Created an attachment (id=16651)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16651&action=view)
chinese example, includes fo, pdf before and after patch


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 36977] - [PATCH]TextLayoutManager CJK line break

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36977





--- Additional Comments From [EMAIL PROTECTED]  2005-10-11 06:59 ---
Every CJK indeographic is a LETTER. A sentence is a sequence of letters and
punctuations with NO space required between them.

Line breaking rules:
A feasible breaking point befor and after a CJK letter, except the follwing
punctuations rules.

Line breaking is NOT allowed after a punctuation which belongs:
unicode General Category Pi [Punctuation, Initial quote]
unicode General Category Ps [Punctuation, Open]

Line breaking is NOT allowed before a punctuation which belongs:
unicode General Category Pf [Punctuation, Final quote]
unicode General Category Pe [Punctuation, Close]
unicode General Category Po [Punctuation, Other] and Line Break IS [Infix
Separator (Numeric)]
unicode General Category Po [Punctuation, Other] and Line Break CL [Closing
Punctuation]
unicode General Category Po [Punctuation, Other] and Line Break NS [Non Starter]
unicode General Category Po [Punctuation, Other] and Line Break EX
[Exclamation/Interrogation]

The rules is trivial. So it's better to let java.text.BreakIterator take care 
of it.


Typesetting Adjustment: (For Chinese, Japanese and Korea is uncertain)
Terms:
HALFWIDTH: most western character, width is about half of height.
FULLWIDTH: most CJK character, width is about equal height.
LEFTHALFGLYPH: some CJK punctuation, the glyph only occupy the left 
half width.
such as \u300B \u201D
RIGHTHALFGLYPH: some CJK punctuation, the glyph only occupy the right 
half
width. such as \u300A \u201C
NOTE: some letters, for example \u201C, is HALFWIDTH in western fonts. In this
case, it's glyph occupy whole width, not be considered as HALFGLYPH.

Adjustment Rules:
R1. If a RIGHTHALFGLYPH follows by a RIGHTHALFGLYPH(IDEOGRAPHIC_FULL_STOP,
RIGHT_DOUBLE_QUOTATION_MARK), the first one should be compressed to it's
minimum, half width.(opt=half_width, shrink=0)
A LEFTHALFGLYPH follows by a LEFTHALFGLYPH would not occur in normal text. Don't
consider.

R2. Between a FULLWIDTH letter and a HALFWIDTH letter or digit, a small sapce is
advised. The samll sapce is set to (opt=half_sapce, shrink=half_sapce)

R3. Between 2 FULLWIDTH letter, a small shrink is allowed. 1/16 of width would
be good to avoid glyph overlapping. The feature should be configurable.

R4. When a line stretch, all feasible breaking point is stretchable. The stretch
of a glue between 2 CJK Letter should be smaller than the glue following a
punctuation. The ratio is not considered yet. Currently, the TextLayoutManager
is not consider it even for western style layout(space between words/space
following sentence end dot). 

R5. When a line shink, first compress HALFGLYPH, HALFGLYPH can be compressed to
half width. 2nd, compress the samll sapce between FULLWIDTH letter and HALFWIDTH
letter or digit (R2). 3rd, shrink the letterspace(R3).
The shrink priority is hard to implement unless modify the knuth algorithm.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: Inline border / padding and nested blocks

[Simon Pepping]

On Mon, Oct 10, 2005 at 02:38:47PM +0200, Luca Furini wrote:
> Manuel Mall wrote:
> 
> >"inline_border_padding_block_nested.xml". If you run the test case as is 
> >you get a "Expect inline sequence as first sequence when last paragraph 
> >is not null" message.
> 
> The first message refers to the first block in the testcase: I think this 
> has something to do with the correct "mixing" of block and inline 
> sequences, as the content of the inner block is placed in the first line, 
> while it should be in the second.
> 
> The output should be:
> 
>   Before inline
>   starting with a block
>   after block After inline
> 
> but we get
> 
>   starting wit a block
>   Before inine after block After inline
> 
> Note that the text before and after the inline (containing the nested 
> block) appear in the same line, and this means their elements ended up in 
> the same sequence, while they should be in two different sequences.

LineLM expects that the inline sequence 'Before inline' is closed
before the block sequence 'starting with a block' appears. This is not
the case. I think it is because I only programmed for the case that
the same LM ends the inline sequence and starts the block sequence. I
forgot about the possibility we see here, that the LM of the first
inline sequence does not know that its sequence is ended because
the following block sequence is started by a different LM, so that
neither LM closes the inline sequence. I only gave a log message
because I believed that this should not happen. This is not true, and
the case can probably be solved by closing the inline sequence instead
of complaining about it.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Inline border / padding and nested blocks

[Manuel Mall]

On Mon, 10 Oct 2005 09:38 pm, Luca Furini wrote:
> Manuel Mall wrote:
> > Is that actually conceptually the right thing to do, that is
> > removing the trailing spaces before the end of a block as part of
> > the Knuth handling?
> >
> > For leading spaces it is done somewhere completely different (and
> > currently in the same piece of code it is done incorrectly for
> > embedded spaces).
>
> I'm not sure it is the best place to do it, although I think that
> before the breaks are computed trailing spaces should exist no more:
> otherwise, the content width would take into account the width of
> these spaces too, and right / center alignment could be incorrect.
>
> Moreover, a glue just before the elements appended by the LineLM
> could be a feasible break, and this would create an empty page after
> the last one with some content.
>
> In other words, that removal is there as it could not be performed
> any later: but the sooner we get rid of the trailing spaces, the
> better! :-)
>
> > I have a picture in mind with all white space handling done as part
> > of the layout (area tree building) but before the actual Knuth
> > sequences are constructed. But that's only a rough idea driven by
> > the description of white space handling in the 1.1WD.
>
> Would you like to share it with us? I always find the specs quite
> obscure as far as white space handling is concerned, so your
> explanation could really be of great help!
>
This needs quite a bit more thought. Currently, and this is certainly 
shifting ground,  I am considering the following approach. We need to 
pass whitespace handling information down the Inline LMs via the layout 
context. The layout context will have the basic information about the 
relevant values of the white space handling related properties and 
state information related to it as well. The state information may be 
just a counter for the number of consecutive eligible spaces 
encountered so far and some indication if anything has been generated 
so far. No Knuth elements for spaces are generated until a non space 
character is encountered. Then whitespace handling for the pending run 
of spaces is done. This may involve discarding the whole run if its the 
first in the block (and the white space properties allow it) or 
generating different Knuth sequences based on the setting of the 
white-space related properties. For example if we have 
suppress-before-linebreak we need a Knuth sequence that "throws the 
space away" if we break before it but "leaves the space" if we break 
after it. This gets even more interesting(?) if we have a run of spaces 
(non collapsing) but with suppress before/after/always around a 
linebreak. Again we would need to design the Knuth sequences to handle 
this correctly. Trailing spaces are handled by looking if any unhandled 
spaces are left when the getNextKnuthElements call returns to the top 
inline level (LineLayoutManager) and are then dealt with.

I feel a WIKI page upcoming similar to Jeremias space handling...

> Regards
>  Luca

Manuel

Re: Some notes about space-before and space-after in the area tree

[Manuel Mall]

On Mon, 10 Oct 2005 09:22 pm, Jeremias Maerki wrote:
> Manuel recently introduced the space-before and space-after traits on
> areas. Right now we're using empty blocks to create spaces between
> areas, except for lineAreas where Manuel started to use the
> space-before and space-after traits. Now that space resolution
> collapses a lot of spaces due to stacking constraints I have to touch
> a lot of test cases to make them work again, so I thought I'd also
> change the code that generates the spaces to use the space-before and
> space-after traits.
>
> In this context it is important to note that our Area.getBPDA
> (=allocated BPD) does not directly relate to the allocation
> rectangles defines in 4.2.3. It includes space-before and
> space-after, so cursor advancement still works, now that the empty
> space areas are not generated anymore (at least in my local code).

It wouldn't be too much of a problem to exclude the space-before/-after 
values from the bpda. We could provide a getTotalBPD function instead 
which takes the space-before/-after values into account and let the 
renderers use that to increment the BPD. The getBPDA method would then 
stay as before (only that nobody is using it). In either case the BPDA 
or TotalBPD are simply calculated values based on all or some of the 
BPD, border, padding and space traits.
>
> Jeremias Maerki
Manuel

Re: Inline border / padding and nested blocks

[Luca Furini]

Manuel Mall wrote:

Is that actually conceptually the right thing to do, that is removing 
the trailing spaces before the end of a block as part of the Knuth 
handling?


For leading spaces it is done somewhere completely different (and 
currently in the same piece of code it is done incorrectly for embedded 
spaces).


I'm not sure it is the best place to do it, although I think that before 
the breaks are computed trailing spaces should exist no more: otherwise, 
the content width would take into account the width of these spaces too, 
and right / center alignment could be incorrect.


Moreover, a glue just before the elements appended by the LineLM could be 
a feasible break, and this would create an empty page after the last one 
with some content.


In other words, that removal is there as it could not be performed any 
later: but the sooner we get rid of the trailing spaces, the better! :-)


I have a picture in mind with all white space handling done as part of 
the layout (area tree building) but before the actual Knuth sequences 
are constructed. But that's only a rough idea driven by the description 
of white space handling in the 1.1WD.


Would you like to share it with us? I always find the specs quite obscure 
as far as white space handling is concerned, so your explanation could 
really be of great help!


Regards
Luca

Some notes about space-before and space-after in the area tree

[Jeremias Maerki]

Manuel recently introduced the space-before and space-after traits on
areas. Right now we're using empty blocks to create spaces between areas,
except for lineAreas where Manuel started to use the space-before and
space-after traits. Now that space resolution collapses a lot of spaces
due to stacking constraints I have to touch a lot of test cases to make
them work again, so I thought I'd also change the code that generates
the spaces to use the space-before and space-after traits.

In this context it is important to note that our Area.getBPDA
(=allocated BPD) does not directly relate to the allocation rectangles
defines in 4.2.3. It includes space-before and space-after, so cursor
advancement still works, now that the empty space areas are not
generated anymore (at least in my local code).

Jeremias Maerki

Re: Problem with table-cell border

[Chris Bowditch]

Yury Litvinov wrote:


Hi,

would you please have a look at that FO example.

==
  
 
 

 
  
	 
	   

  
 
   one

  
  
  


   
 two
 
  

  
  
  


After starting FOP we get:
Exception java.lang.ArrayIndexOutOfBoundsException: -1


Assuming you are using latest FOP from SVN Trunk, then the problem is 
caused by fact that you are using the border-collapse="collapse" 
setting. Even though you haven't specified this on the table element, it 
is the default value for this setting. If you specify




then the example should work.



Chris

Re: Inline border / padding and nested blocks

[Manuel Mall]

On Mon, 10 Oct 2005 08:38 pm, Luca Furini wrote:
> Manuel Mall wrote:

> > If you comment everything out and uncomment the last block you get
> > a ClassCastException on a Knuth element.
>
> This happens during LineLM.removeElementsForTrailingSpaces(): as you
> wrote some time ago, at the moment when the LineLM meets a glue
> element at the end of a sequence it could wrongly deduce it
> represents a trailing space, while it represents borders / paddings.
>
> I'm going to look at the possible "patterns" that the elements for
> border and padding can have, and fix the method.
>
Luca,

thanks for looking at this so quickly. 

Is that actually conceptually the right thing to do, that is removing 
the trailing spaces before the end of a block as part of the Knuth 
handling?

For leading spaces it is done somewhere completely different (and 
currently in the same piece of code it is done incorrectly for embedded 
spaces).  I have a picture in mind with all white space handling done 
as part of the layout (area tree building) but before the actual Knuth 
sequences are constructed. But that's only a rough idea driven by the 
description of white space handling in the 1.1WD.

> Regards
>  Luca

Manuel

Re: Problem with table-cell border

[Manuel Mall]

On Mon, 10 Oct 2005 08:16 pm, Yury Litvinov wrote:
> Hi,
>
> would you please have a look at that FO example.
>
> ==
>   
> 	 
>  
>
> 	 
>   
>
> 	   
>   
> border-width="1pt" padding="7pt">
>  
>one
> 
>   
>   
>
> 
>
>  two
>  
>   
>
>   
>   
>   
> 
>
> After starting FOP we get:
> Exception java.lang.ArrayIndexOutOfBoundsException: -1
>
> But if we replace
> padding="7pt" by padding="6pt"
> in line 
> padding="7pt">, we won't get any exception.
>
> Does anyone have any suggestions on how to sort out the problem?
>

Unfortunately not really. A similar problem has been reported before http://issues.apache.org/bugzilla/show_bug.cgi?id=36403 but has not yet been fixed.

> Good luck.

Manuel

Re: Inline border / padding and nested blocks

[Luca Furini]

Manuel Mall wrote:

"inline_border_padding_block_nested.xml". If you run the test case as is 
you get a "Expect inline sequence as first sequence when last paragraph 
is not null" message.


The first message refers to the first block in the testcase: I think this 
has something to do with the correct "mixing" of block and inline 
sequences, as the content of the inner block is placed in the first line, 
while it should be in the second.


The output should be:

  Before inline
  starting with a block
  after block After inline

but we get

  starting wit a block
  Before inine after block After inline

Note that the text before and after the inline (containing the nested 
block) appear in the same line, and this means their elements ended up in 
the same sequence, while they should be in two different sequences.


I'm going to look at what happens in detail ...

If you comment everything out and uncomment the last block you get a 
ClassCastException on a Knuth element.


This happens during LineLM.removeElementsForTrailingSpaces(): as you wrote 
some time ago, at the moment when the LineLM meets a glue element at the 
end of a sequence it could wrongly deduce it represents a trailing space, 
while it represents borders / paddings.


I'm going to look at the possible "patterns" that the elements for border 
and padding can have, and fix the method.


Regards
Luca

Problem with table-cell border

[Yury Litvinov]

Hi,

would you please have a look at that FO example.

==
  
 
 

 
  
 
   
  
 
   one

  
  
  

   
 two
 
  

  
  
  


After starting FOP we get:
Exception java.lang.ArrayIndexOutOfBoundsException: -1

But if we replace
padding="7pt" by padding="6pt" 
in line , we won't get any exception.

Does anyone have any suggestions on how to sort out the problem?

Good luck.

DO NOT REPLY [Bug 36934] - The collapsing border model on an fo:table is currently not supported by FOP

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36934





--- Additional Comments From [EMAIL PROTECTED]  2005-10-10 12:08 ---
The warning message appears because the default value according to XSL-FO spec 
is border-collapse="collapse" If this property is not specified on fo:table 
then FOP currently struggles to render the document, since the collapsing 
model is currently implemented. The solution is simply to specify border-
collapse="separate" on every occurrence of fo:table. FOP 1.0 then renders the 
document fine.

I agree with Jeremias' assesment that table support in 0.20.5 is no better 
than in FOP 1.0

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Small rounding problem with improved line building

[Jeremias Maerki]

Manuel,

would you please have a look at the FO file I posted for the space
interpretation stuff? 

http://people.apache.org/~jeremias/fop/space-interpretation.fo

The file forces a line-height of 1mpt but the element list and the
area tree will create a line height of mpt. Not that it's a big
problem on the visual side, but it is somewhat unexpected when you deal
with test cases. The reason for this is
LineLayoutManager.LineBreakingAlgorithm.makeLineBreakPosition() (the
first statement). I'm not sure where to add the rounding difference.
Maybe it can simply be added to "follow" or the second halfLeading
becoming space-after could be incremented by 1 mpt. 

Thanks,
Jeremias Maerki

DO NOT REPLY [Bug 36238] - text-align="justify" doesn't work on custom fonts

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36238





--- Additional Comments From [EMAIL PROTECTED]  2005-10-10 10:09 ---
To document what's wrong, here are two PDF lines generated once with FOP 0.20.5
and once with FOP Trunk. This illustrates what is done differently:

Fop 0.20.5:
1 0 0 1 56.692 678.637 Tm [<00040005000600070008> -293.0 <0009000a000b000c0008>
-293.0 <000d0005000e00050006> -293.0 <000b0009000f> -293.0
<00180007000f0011> -293.0 <001200050013000b00070012000f0007000f000c00070006>
-293.0 <001d0009000a0009000b0012000900130014> -293.0 <0007000e0009000f0015>
-293.0 <00160013> -293.0 <0017000c0009000b> -293.0
<000f00050006000f000500060015> -293.0 <00180019001b0007000e000e000c000b>
-293.0 <001f> -293.0 <0005000600120009> -293.0 <00100012> ] TJ

FOP Trunk:
1 0 0 -1 0.0 112.164 Tm 0.0 Tc 1.437 Tw
[<000500060007000800090003000A000B000C000D00090003000E0006000F000600070003000C000A0013001100090008001000120003001300060014000C000800130018001D0008000700030011000E000A000B000A000C0013000A0014001500030008000F000A0010001600030017001400030018000D000A000C00030016000700160007001600030019001A0011000C0008000F000F000D000C000300110013000600070013000A>
] TJ

Looks like the spaces don't get recognized by the PDF implementation this way.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.