DO NOT REPLY [Bug 37743] exception: border-style (shorthand)

2012-03-31 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=37743

Glenn Adams  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #7 from Glenn Adams  2012-04-01 06:27:00 UTC ---
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed

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

DO NOT REPLY [Bug 37743] - exception: border-style (shorthand)

2006-03-07 Thread 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=37743


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2006-03-07 15:38 ---
*** Bug 38882 has been marked as a duplicate of this bug. ***

-- 
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 37743] - exception: border-style (shorthand)

2005-12-27 Thread 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=37743


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-12-28 04:28 ---
Fixed, actually more a hack/workaround.

See: http://svn.apache.org/viewcvs?rev=359364&view=rev and 
http://svn.apache.org/viewcvs?rev=359368&view=rev

Sorry, messed up the commits so the bug fix is spread over two svn commits.

-- 
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: DO NOT REPLY [Bug 37743] - exception: border-style (shorthand)

2005-12-09 Thread Luca Furini 

Manuel Mall wrote:

c) Your initial thought is that the Line LM should then provide enough 
information to the LMs to generate their Knuth sequences while my 
initial thought is that the Line LM generates the Knuth sequences and 
provides enough information for the LMs to generate their areas.


If you agree with this summary may be we can concentrate on discussing 
the pros and cons of the two approaches mentioned in item c) above?


Who should generate the elements?

1) the inline LMs

pros:

+ the LineLM needs to know only the text from its inline children

+ the LineLM would work only on the collected text; the output that must 
be sent to the inline LMs (the set of breaking points, hyphenation points, 
collapsed spaces) would be quite simple


+ each inline LM already knows the relevant properties affecting the size 
of the elements (font-size, word-spacing, letter-spacing, borders and 
paddings) so the generation would be easily done


+ while creating the elements, the inline LMs uses the same information to 
create area properties


cons:

- many function calls to get the elements (another tree walk of the LM tree)

- [add your cons here!]

2) the LineLM

Well, the inverted pros and cons!

My main concern about this approach is complexity: while the text is a 
"flattened representation" of the fo tree, so that the LineLM can easily 
find all kind of breaking / hyphenation points regardless of fo 
boundaries, the properties cannot be so easily flattened; in order to know 
the font-size of a character the LineLM would need either a lot of 
information (where each fragment starts and ends, and two nested inlines 
can define up to 5 "fragments") or a tree (but in this case whouldn't it 
be quite similar to the LM tree?).


But maybe I just have not yet understood your idea ...

Regards
Luca

Re: DO NOT REPLY [Bug 37743] - exception: border-style (shorthand)

2005-12-06 Thread Manuel Mall 
On Tue, 6 Dec 2005 03:36 am, Simon Pepping wrote:
> On Mon, Dec 05, 2005 at 09:10:06PM +0800, Manuel Mall wrote:
> > Luca,
> >
> > Glyphs are only allowed to be merged if they carry the same /
> > matching set of property values. Personally I would not be
> > concerned if we therefore limit that logic to within a LM. While it
> > is possible that someone could write something like
> > ä
> > and the a and ̈ could be combined into an &x00e4; IMO this
> > is a pretty degenerated case.
>
> One cannot write this. The Reader would probably combine >̈,
> after which a not-well-formed XML file would result. The text is not
> fully normalized, see
> http://www.w3.org/TR/2005/WD-charmod-norm-20051027/#sec-FullyNormaliz
>ed.

Yes I agree that the text is not fully normalised as defined in 
WD-charmod-norm-20051027. But, neither the XSL-FO nor the XML spec 
require the input to be normalised.

>
> Simon

Manuel

Re: DO NOT REPLY [Bug 37743] - exception: border-style (shorthand)

2005-12-05 Thread Simon Pepping 
On Mon, Dec 05, 2005 at 09:10:06PM +0800, Manuel Mall wrote:
> Luca,
> 
> Glyphs are only allowed to be merged if they carry the same / matching 
> set of property values. Personally I would not be concerned if we 
> therefore limit that logic to within a LM. While it is possible that 
> someone could write something like
> ä
> and the a and ̈ could be combined into an &x00e4; IMO this is a 
> pretty degenerated case.

One cannot write this. The Reader would probably combine >̈,
after which a not-well-formed XML file would result. The text is not
fully normalized, see
http://www.w3.org/TR/2005/WD-charmod-norm-20051027/#sec-FullyNormalized.

Simon

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

Re: DO NOT REPLY [Bug 37743] - exception: border-style (shorthand)

2005-12-05 Thread Luca Furini 

Manuel Mall wrote:

I wonder if the same argument does apply to kerning as well? The moment 
you change font-size, text-decoration, background-color, alignment and 
the like, which is what fo:inline is mainly for, you create a barrier 
with respect kerning. Or to put it differently, I believe kerning 
applies only to "like" characters, same as glyph merging.


Not sure here: if we want to use kerning between, for example, "VA" I 
think it would be even more desirable to use it if the V has a bigger font 
size, or the A a smaller one; it could maybe need some heuristic to handle 
a kerning between character with different sizes, but I think it would be 
a desirable feature.


Nonetheless, I agree that the think may become strange with different 
backgrounds or vertical alignments ... maybe we should define which 
properties "break" a kerning pair ...


Regards
   Luca

Re: DO NOT REPLY [Bug 37743] - exception: border-style (shorthand)

2005-12-05 Thread Jeremias Maerki 
AFAIK, there's no such flag in XSL-FO. In 0.20.5 this was simply
controlled per font over its configuration. We'd have to create an
extension property to locally switch off kerning once it's available.

On 05.12.2005 16:18:25 Manuel Mall wrote:

> Side note: Does XSL-FO provide any user control over kerning? I couldn't 
> identify a property an author could use to switch kerning on/off for a 
> particular section of text. Isn't something like that needed for high 
> quality type setting?



Jeremias Maerki

Re: DO NOT REPLY [Bug 37743] - exception: border-style (shorthand)

2005-12-05 Thread Manuel Mall 
On Mon, 5 Dec 2005 10:53 pm, Luca Furini wrote:
> First of all, thanks for your comments: I really tend to forget in a
> short time all the details concerning white space!
>
> Manuel Mall wrote:
> > Glyphs are only allowed to be merged if they carry the same /
> > matching set of property values. Personally I would not be
> > concerned if we therefore limit that logic to within a LM. While it
> > is possible that someone could write something like
> > ä
> > and the a and ̈ could be combined into an &x00e4; IMO this
> > is a pretty degenerated case.
>
> Seems reasonable: so, we can delete glyph substitution from the list
> of things we must consider in this phase.
>
> But, now I think of it, we must consider kerning too, so the list
> does not get any thinner!
>
I wonder if the same argument does apply to kerning as well? The moment 
you change font-size, text-decoration, background-color, alignment and 
the like, which is what fo:inline is mainly for, you create a barrier 
with respect kerning. Or to put it differently, I believe kerning 
applies only to "like" characters, same as glyph merging.

Of course kerning needs to be considered as part of hyphenation as it 
may cause some minor width corrections if the hyphen is inserted 
between two characters who have a non zero kerning pair value. And vice 
versa if a soft hyphen is removed. But that is a different issue.

Side note: Does XSL-FO provide any user control over kerning? I couldn't 
identify a property an author could use to switch kerning on/off for a 
particular section of text. Isn't something like that needed for high 
quality type setting?



Manuel

Re: DO NOT REPLY [Bug 37743] - exception: border-style (shorthand)

2005-12-05 Thread Jeremias Maerki 

On 05.12.2005 15:53:51 Luca Furini wrote:
> First of all, thanks for your comments: I really tend to forget in a short 
> time all the details concerning white space!
> 
> Manuel Mall wrote:
> 
> > Glyphs are only allowed to be merged if they carry the same / matching 
> > set of property values. Personally I would not be concerned if we 
> > therefore limit that logic to within a LM. While it is possible that 
> > someone could write something like
> > ä
> > and the a and ̈ could be combined into an &x00e4; IMO this is a 
> > pretty degenerated case.
> 
> Seems reasonable: so, we can delete glyph substitution from the list of 
> things we must consider in this phase.
> 
> But, now I think of it, we must consider kerning too, so the list does not 
> get any thinner!

I may even be able to make the list even longer: font-variant support,
font-selection-strategy="character-by-character". I don't want to make
this any harder but maybe it's worth having at least a short glance at
the two properties while you're at it. But I'm not sure if it really
plays into the current topic.




Jeremias Maerki

Re: DO NOT REPLY [Bug 37743] - exception: border-style (shorthand)

2005-12-05 Thread Luca Furini 
First of all, thanks for your comments: I really tend to forget in a short 
time all the details concerning white space!


Manuel Mall wrote:

Glyphs are only allowed to be merged if they carry the same / matching 
set of property values. Personally I would not be concerned if we 
therefore limit that logic to within a LM. While it is possible that 
someone could write something like

ä
and the a and ̈ could be combined into an &x00e4; IMO this is a 
pretty degenerated case.


Seems reasonable: so, we can delete glyph substitution from the list of 
things we must consider in this phase.


But, now I think of it, we must consider kerning too, so the list does not 
get any thinner!



my summary is:

a) We both seem to want the same outcome, that is add required features 
and at the same time get rid of some of the workarounds currently used.


Agreed.

b) We both agree that the character by character analysis is done at 
Line LM level.


Agreed.

c) Your initial thought is that the Line LM should then provide enough 
information to the LMs to generate their Knuth sequences while my 
initial thought is that the Line LM generates the Knuth sequences and 
provides enough information for the LMs to generate their areas.


If you agree with this summary may be we can concentrate on discussing 
the pros and cons of the two approaches mentioned in item c) above?


Ok, I'll send a new message soon!

Regards
Luca

Re: DO NOT REPLY [Bug 37743] - exception: border-style (shorthand)

2005-12-05 Thread Manuel Mall 
Luca,

great summary and I appreciate you taking a serious look into this 
problem. Some comments below.

On Mon, 5 Dec 2005 05:48 pm, Luca Furini wrote:
> Manuel Mall wrote:
> > After that we really need to redesign the line breaking stuff. Not
> > the Knuth approach (and the implemented algorithms related to that)
> > but the way we arrive at the Knuth sequences and iterate and
> > process the text elements. This needs to be done to be able to do
> > white-space-treatment, UAX#14 line breaking, start- /end- space
> > resolution and generally to be able to handle some more aspects of
> > Unicode (e.g. glyph merging).
>
> Just trying to write down a few thoghts and summarise what we have
> already said about this:
>
> - the inline LMs can directly apply the linefeed-treatment property
> (ignoring, preserving or transforming the LF character) but have too
> much a limited "view" to handle correctly white-space-treatment and
> white-space-collapse, and to count the number of letter spaces
>

I would formulate the problem slightly differently:

The line breaking logic requires inspection of adjacent characters in 
the input, even if these characters are contained in different inline 
fo's, in the following cases:
a) To determine line break possibilities in accordance with the Unicode 
Annex UAX#14
b) To be able to apply the white-space-treatment property around FOP 
generated line breaks
c) To determine word boundaries, which are used
i) to calculate the number of letter spaces in a word
ii) to determine the actual words presented to the hyphenation 
algorithm

> - the LineLM has to collect the "text" from its descendant nodes:
> non-textual objects should be taken into account too, as, for
> example, a leader between two spaces should prevent them from being
> collapsed; if spaces collapse only if they come from sibling nodes,
> this could maybe be handled during the collection by the
> InlineStackingLM

I have a slightly different view on the handling of spaces. We only need 
to be concerned about white-space-treatment around line breaks we 
generate. Everything else is already dealt with by the time the LM are 
invoked. This in turn means IMO we only need to know how "big" the glue 
element needs to be which is dropped if a line break is actually 
generated by the Knuth algorithm. Determining the value for "big" 
however means we need to consider adjacent spaces even if contained in 
different inline fo's.

>
> - the LineLM should then mark spaces that must be removed because
> they are trailing / leading, glyphs that must be merged (but which LM
> will paint them if the characters come from different text nodes?)
> and find the breaking points according to the unicode rules

Glyphs are only allowed to be merged if they carry the same / matching 
set of property values. Personally I would not be concerned if we 
therefore limit that logic to within a LM. While it is possible that 
someone could write something like
ä
and the a and ̈ could be combined into an &x00e4; IMO this is a 
pretty degenerated case.

>
> - the LineLM should give someway the computed information to the
> descendant LM, that would use it to create at once the correct
> elements

Yes it could, but I am in two minds if this is the best approach or if 
the Line LM should create the Knuth sequences right away and store in 
them enough information so that during the addAreas phase the inline 
LMs can create the correct areas.

>
> - the resulting sequences would be ready for the breaking phase,
> without further analysis / checks / substitutions / changes
>
> The revised interface for inline LMs could then have (just a quick
> idea) a new appendText(StringBuffer) method and a modified version of
> getNextKnuthElements() having some extra parameter storing the
> information created by the LineLM; we should finally get rid of
> addALetterSpaceTo(), getWordChars(), hyphenate(), applyChanges() and
> getChangedKnuthElements().

Yes, we both seem to look for the same outcome.  My (certainly not fully 
thought through) model was more along the lines of the iterator 
approach used by the fo's to iterate over its char sequences during 
refinement. However, the iterator should probably not just return a 
character but enough information for the Line LM to build the area info 
objects to attach to the Knuth elements so that the add areas phase 
works correctly later.
 
>
> WDYT?

Very good discussion - my summary is:

a) We both seem to want the same outcome, that is add required features 
and at the same time get rid of some of the workarounds currently used.

b) We both agree that the character by character analysis is done at 
Line LM level.

c) Your initial thought is that the Line LM should then provide enough 
information to the LMs to generate their Knuth sequences while my 
initial thought is that the Line LM generates the Knuth sequences and 
provides enough information for the LMs to generate their areas.

If you agree with

Re: DO NOT REPLY [Bug 37743] - exception: border-style (shorthand)

2005-12-05 Thread Luca Furini 

Manuel Mall wrote:

After that we really need to redesign the line breaking stuff. Not the 
Knuth approach (and the implemented algorithms related to that) but the 
way we arrive at the Knuth sequences and iterate and process the text 
elements. This needs to be done to be able to do white-space-treatment, 
UAX#14 line breaking, start- /end- space resolution and generally to be 
able to handle some more aspects of Unicode (e.g. glyph merging).


Just trying to write down a few thoghts and summarise what we have already 
said about this:


- the inline LMs can directly apply the linefeed-treatment property 
(ignoring, preserving or transforming the LF character) but have too much 
a limited "view" to handle correctly white-space-treatment and 
white-space-collapse, and to count the number of letter spaces


- the LineLM has to collect the "text" from its descendant nodes: 
non-textual objects should be taken into account too, as, for example, a 
leader between two spaces should prevent them from being collapsed; if 
spaces collapse only if they come from sibling nodes, this could maybe be 
handled during the collection by the InlineStackingLM


- the LineLM should then mark spaces that must be removed because they are 
trailing / leading, glyphs that must be merged (but which LM will paint 
them if the characters come from different text nodes?) and find the 
breaking points according to the unicode rules


- the LineLM should give someway the computed information to the 
descendant LM, that would use it to create at once the correct elements


- the resulting sequences would be ready for the breaking phase, without 
further analysis / checks / substitutions / changes


The revised interface for inline LMs could then have (just a quick idea) a 
new appendText(StringBuffer) method and a modified version of 
getNextKnuthElements() having some extra parameter storing the information 
created by the LineLM; we should finally get rid of addALetterSpaceTo(), 
getWordChars(), hyphenate(), applyChanges() and getChangedKnuthElements().


WDYT?

Regards
Luca

DO NOT REPLY [Bug 37743] - exception: border-style (shorthand)

2005-12-05 Thread 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=37743





--- Additional Comments From [EMAIL PROTECTED]  2005-12-05 10:18 ---
Sorry for not answering before, today I hope I'll be able to find some time to
look at this.
Thanks to you all, the problem has already been defined with precision.

As Manuel rightly said, however, we should rethink this part of the process in
order to solve this kind of problem once and for all.

-- 
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 37743] - exception: border-style (shorthand)

2005-12-02 Thread 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=37743


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|exeption: border-style  |exception: border-style
   |(shorthand) |(shorthand)




--- Additional Comments From [EMAIL PROTECTED]  2005-12-02 13:10 ---
The problem is (again) that the breaking text into lines and words logic 
crosses inline boundaries and our nested inline processing is getting really in 
the way. To get around this the code has to 'jump through hoops'. In this case 
the Knuth sequences returned by getNextKnuthElement are used to reverse 
engineer words which extend over an inline boundary. This in turn needs to be 
done to determine if an additional letter space needs to be added as the 
individual LMs don't do that at a boundary because they don't know if they 
start/end at the beginning/end of a word or in the middle of a word.

Of course this "ranting" about the problem will not get us a solution. In the 
very short term may be Luca can have a look at this as he as fixed a similar 
problem before in a related area.

After that we really need to redesign the line breaking stuff. Not the Knuth 
approach (and the implemented algorithms related to that) but the way we arrive 
at the Knuth sequences and iterate and process the text elements. This needs to 
be done to be able to do white-space-treatment, UAX#14 line breaking, start-
/end- space resolution and generally to be able to handle some more aspects of 
Unicode (e.g. glyph merging).

-- 
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.