Re: Plan: Branch for page breaking

2005-03-18 Thread Luca Furini
Jeremias Maerki wrote: I'd like to tag CVS HEAD tomorrow and then branch it and commit my local working copy to that branch. From there I'll continue to work on static regions, lists and finally tables (actually resurrecting that functionality). In the last two weeks I worked on lists, and they

Re: Creating combined element lists for a table row from cell element lists

2005-03-29 Thread Luca Furini
Jeremias Maerki wrote: I thought I could come up with a combined element list for this one, too, but so far I haven't managed. At last I'm here! I start with a question I could not find an answer to: is row splitting allowed by default and forbidden using keep-together, or is it forbidden

Error in LabelEndFunction?

2005-04-08 Thread Luca Furini
I was trying to make lists work in the most general situation when I stumbled across this strange bug: it seems that the label-end() function (implemented in fo/expr/labelEndFunction.java) does not compute the right value. It should compute the end-indent of a list-item-label, which is defined

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr FlowLayoutManager.java

2005-04-13 Thread Luca Furini
Glen Mazza wrote: Hi Luca, 1.) Can the corresponding setting of these values on fo:root (642-643 of [1]) in PSLM now be removed? (I think so...because what is set on fo:flow will be used instead of fo:root.) I agree with you. The method LengthBase.getBaseLength() (which is called by

Some doubts about lists

2005-04-14 Thread Luca Furini
Working on lists, I found a couple of paragraphs in the recommendation whose meaning is not fully clear to me. Section 6.8.3. (fo:list-item) states that: the block-progression-dimension of the content-rectangle of an area generated by the fo:list-item is just large enough so that the

Re: Some doubts about lists

2005-04-15 Thread Luca Furini
Andreas L. Delmelle wrote: IIC, what is meant is: the space-* of the contained blocks should be seen as _content_ of the list-item, such that they are not ignored, but their values are _included_ in the total BPD without influencing the spacing between previous and following list-items.

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr/list ListItemLayoutManager.java

2005-04-15 Thread Luca Furini
I wrote: Creating a combined list for label and body I forgot to mention that this work is mainly based on Jeremias' code for tables. There is only a significant difference while computing the first step: +if (backupHeights[0] == 0 backupHeights[1] == 0) { +// this is

Re: Branch deadline coming up

2005-04-20 Thread Luca Furini
Simon Pepping wrote: I noticed that each line in a paragraph has the height of the first line of that paragraph. That is not correct, and may invalidate test files. You are right, but this can be easily fixed. At the moment each created box has height = constantLineHeight: I added this trick

Problems with break conditions and empty pages

2005-04-21 Thread Luca Furini
It seems there is a bug affecting the creation of the right kind of page for documents containing blocks with break-* = odd-page or even-page. If break-before = odd-page *each* page with some content is odd; even pages are all empty. If break-before = even-page the content is placed only on even

Re: Problems with break conditions and empty pages

2005-04-22 Thread Luca Furini
Glen Mazza wrote : # Andreas L. Delmelle wrote: 1.) If FOP is processing a block on the middle of page 17 with a break-before value of even-page, FOP is supposed to render this block at the top of page 18 instead. I agree. 2.) If FOP is processing a block on the middle of page *18* with

Re: Problems with break conditions and empty pages

2005-04-26 Thread Luca Furini
Sorry for the long weekend of absence, but April 25th is a public holiday in Italy! :-) Andreas L. Delmelle wrote: Further browsing leads me to place my money on AbstractBreaker.BlockSequence. If I get it correctly, the 'startOn' value is set only once for the entire list (at construction

Applying Finn Bock's patch (again) :-)

2005-05-02 Thread Luca Furini
I realized just a few days ago that the breaking algorithm (in the BreakingAlgorithm class) is not fully patched with Finn's great refactoring of the Knuth code (bug 32612). I must admit that this is due to my laziness: when I was playing with Knuth's algorithm for page breaking I applied to my

Re: More table borders

2005-05-09 Thread Luca Furini
Jeremias Maerki wrote: So far I can only see the brute-force method (discarding element lists after the break and somehow backtrack while cleverly optimizing so as not to create too many discarded objects - still a non-trivial thing over all). Andrea's idea of recycling elements instead of

Re: [VOTE] Merge Knuth branch back into HEAD

2005-05-11 Thread Luca Furini
Jeremias Maerki wrote: Still, we're at a point where we should finally say yes or no to further pursuing the new page breaking approach. Merging the branch back into HEAD means a step back for a few features and on the other side a step forward especially for keeps. My vote is +1 Over

Re: merging the two branches

2005-05-13 Thread Luca Furini
Jeremias Maerki wrote: Ok, I'm planning to do this on Saturday. I was hoping to get a comment from Luca since he said he's working on footnotes and I don't want to make his life harder than necessary. Oops, sorry, I did not mean to delay the merge! I still have to solve some problems

Footnotes working!

2005-05-17 Thread Luca Furini
Footnotes should be working now. At the moment the page breaking algorithm is quite strict: it tries to insert every footnote in the same page where their citation is (the last footnote body could be split, and partially deferred to the next page). The recommendation seems to suggest that it

Re: Markers: Determining the last generated area for a LM

2005-05-24 Thread Luca Furini
Jeremias Maerki wrote: The isfirst and islast parameters must be set correctly. Currently, I don't see a reliable way to determine these values. For example, there's some code in AreaAdditionUtils that sets IS_FIRST and IS_LAST flags on the layout context but I found this doesn't work

Re: Footnotes working!

2005-05-30 Thread Luca Furini
Andreas L. Delmelle wrote: Yeah, as an example: try reading some Postmodern Philosophy... Many pages that are filled for 75% with footnotes offering comments/notes on the ideas that appear on the other 25% (even pages containing nothing *but* footnotes, continued from a previous page). I

Footnotes handling debug

2005-05-31 Thread Luca Furini
I'm trying to correct the footnotes handling, as the testfile footnotes2.xml does not pass yet. I succeeded in handling a page-dependent footnote separator, with the reasonable (at least IMO) assumption that the separator bpd does not change, but there is a check I don't understand: [...]

Re: Footnotes handling debug

2005-06-06 Thread Luca Furini
Jeremias Maerki wrote: Right now, that last empty block creates a block area that has a BPD of 14400. In the end this area should collapse to a BPD of 0 so it doesn't affect the page breaking. A footnote like this is a regular work-around in 0.20.5 and we should have it working again. Or

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr StaticContentLayoutManager.java LineLayoutManager.java AbstractLayoutManager.java TextLayoutManager.java LayoutManagerMapping.java ContentLayo

2005-06-10 Thread Luca Furini
Thanks for your optimization work, Glen. Just a note: the method addALetterSpaceTo() is defined in the interface InlineLevelLayoutManager and is still used. It is called by LineLM.collectInlineKnuthElements(), if the last element returned by a child LM and the first returned by the next child LM

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr StaticContentLayoutmanager.java LineLayoutManager.java AbstractLayoutManager.java TextLayoutManager.java LayoutManagerMapping.java ContentLayo

2005-06-14 Thread Luca Furini
Glen Mazza wrote: Are you sure here? We had two versions of addALetterSpaceTo() -- the version in ILLM which takes a List (I didn't touch that one), and a old (?) version from AbstractLayoutManager that takes a KnuthElement. It is that latter version that I removed--it wasn't being called

Re: Fop Viewer

2005-06-15 Thread Luca Furini
Jeremias Maerki wrote: I'll review his patch tomorrow. I'll also take care of the german and french translations. I can take care of the italian translation. Regards Luca

Failing testcases

2005-06-17 Thread Luca Furini
I noticed that several testcases, not listed among the disabled ones, fail: keep-together2.xml keep-together3.xml keep-together4.xml keep-with-next1a.xml keep-with-next2.xml keep-with-next3.xml keep-with-next4.xml keep-with-next5.xml keep-with-previous1a.xml

Re: multi-column layout and footnotes

2005-06-28 Thread Luca Furini
Jeremias Maerki wrote: I just hope this breaking-up of the span-reference-areas won't cause too many problems with keeping the footnotes working. I'm a bit worried about that. We'll see. I was thinking about this too: the texbook, speaking about footnotes and columns, says something

Re: DO NOT REPLY [Bug 35534] - fo document output is placed in page margins

2005-07-27 Thread Luca Furini
Jeremias Maerki wrote: The situation is now improved here. The missing glues are now produced but if there are shrink and stretch possibilities the spaces are currently not adjusted, i.e. differing .minimum/.optimum/.maximum values on space-before and space-after may produce undesirable

Re: svn commit: r225580 - /xmlgraphics/fop/trunk/test/layoutengine/testcases/page-master4.xml

2005-07-29 Thread Luca Furini
Jeremias Maerki wrote: Add margin on simple-page-master as additional feature. ATM, doesn't this raise a PropertyException saying that Border and padding for a region must be 0? The XSL 1.0 Recommendation states that borders and padding are not allowed with a page-reference-area (6.4.12

Re: svn commit: r226973

2005-08-02 Thread Luca Furini
Adjusting verticals spaces (coming from space-before and space-after properties) in order to fill the region, whenever possible I have done a few tests before committing, with spaces on blocks and on lists (both in the list-block and in the list-items) and it seems to work; should you find

Re: DO NOT REPLY [Bug 35937] - [PATCH] Support for FormattingResults ported from 0.20.5 to 1.0

2005-08-02 Thread Luca Furini
Jeremias Maerki wrote: I agree with the actual concept but I actually want something more general in the long-term. There are various aspects that I'd like to provide to embedders: - Number of pages over all and Number of pages for every page-sequence (obviously) - Callbacks on layout

Re: svn commit: r227219 - /xmlgraphics/fop/trunk/src/documentation/content/xdocs/compliance.ihtml

2005-08-03 Thread Luca Furini
Jeremias Maerki wrote: Initial values for Trunk column. No guarantees! Jeremias, Manuel, you have done a great job! I find it very useful and stimulating to have such a comprehensive to do list at hand! Just a few notes: [page-number-citation] [Trunk] After the page number is known, no

Re: Plain old line-breaking

2005-08-19 Thread Luca Furini
Peter B. West wrote: Is there any design documentation about plain old line Knuth breaking, as implemented by Luca? I see lots of stuff in the Wiki about page breaking, but can't see the original. As Jeremias told, there isn't much official documentation about the basics of the new breaking

page-number and page-number-citation problem

2005-08-26 Thread Luca Furini
There is a layout problem with fo:page-number and fo:page-number-citation, already pointed out but still unresolved. I think, these formatting objects are very similar, even if their actual handling is quite different: they both must be replaced by an information (a page number) that is (or

Re: page-number and page-number-citation problem

2005-08-29 Thread Luca Furini
J.Pietschmann wrote: In the maintenance branch, the formatted page number string was produced just as a new page was set up. I wonder whether the page sequence LM can put the current page number string into the layout context? This could work for page-numbers but not for

Re: page-number and page-number-citation problem

2005-08-29 Thread Luca Furini
Firstly, thank you all for your suggestions. All your interesting replies led me to this conclusion: - in most cases, it is enough to make some local adjustments in each line containing page-numbers or page-number-citations; - sometimes, when a particularly elegant output is needed, it would

Re: page-number and page-number-citation problem

2005-08-30 Thread Luca Furini
J.Pietschmann wrote: Maybe I'm wrong in trying to do so, but I'd like to handle both formatting objects in the same way. If page numbers can be resolved to strings early, it should be done. All the hassle for space readjusting, and perhaps reflowing content, should be reserved for forward

Re: [Xmlgraphics-fop Wiki] Update of ReleasePlanFirstPR by ChrisBowditch

2005-08-31 Thread Luca Furini
Chris Bowditch wrote: + * Conditional space support, i.e. space-before.conditionality=retain Chris, doesn't this work already? As far as I can remember the correct space resolution is still missing, so for example the space-after of a block is not added to the space-after of the following

Re: [Xmlgraphics-fop Wiki] Update of ReleasePlanFirstPR by ChrisBowditch

2005-08-31 Thread Luca Furini
Chris Bowditch wrote: I just knocked up a small test case and although retain is honoured, discard is ignored. I knew it wasn't quite yet working but didn't realise retain was working :) I'll update the Wiki. Could you please also attach your file? I have tested a simple sequence of blocks

Re: [Xmlgraphics-fop Wiki] Update of ReleasePlanFirstPR by ChrisBowditch

2005-08-31 Thread Luca Furini
Chris Bowditch wrote: Here is the sample: Thanks! I have tested a simple sequence of blocks with conditional spaces and the output seems ok; the output of the testcase space-block2.xml seems correct too (I'm going to add checks). Not true, space-block2.xml does not work. On the second

Re: [Xmlgraphics-fop Wiki] Update of ExtensionPoints by JeremiasMaerki

2005-09-02 Thread Luca Furini
Speaking of extensions, I'd like to resurrect the layout extensions that were part of the code used to start the Knuth branch, but I want to be sure I'm allowed to do it. The set of extensions (a couple of new properties, and some new value for an existing one) is aimed to give the user more

Re: FOP Visuals

2005-09-02 Thread Luca Furini
Jeremias Maerki wrote: For those who don't want to run BatchDiffer themselves, I've uploaded a ZIP full of PNGs, one per layout engine test case combined from output from the PDF, PS and Java2D renderers. Just an idea ... what about an option to have the output from two renderers and the XOR

Re: [Xmlgraphics-fop Wiki] Update of ExtensionPoints by JeremiasMaerki

2005-09-02 Thread Luca Furini
Thank you all for your support! Vincent Hennebert wrote: Just a comment about your Wiki page: I'm not sure that modifying margins would produce visually appealing results. May it not disturb the reader when she notices that margins aren't the same after turning a page? Well, that is thought

[VOTE] Manuel Mall as new FOP committer

2005-09-05 Thread Luca Furini
Jeremias Maerki wrote: That's why I'd like to nominate him for committership in Apache FOP. +1 Luca

Re: SVG Image cropping/positioning

2005-09-05 Thread Luca Furini
Richard W. wrote: I'm starting now. I've had to rename inline_block_nested_\#36248.xml to inline_block_nested_bug36248.xml to get the junit task to build. I had to rename that file too; I have win xp. Regards Luca

Re: e-g with padding and borders

2005-09-06 Thread Luca Furini
Manuel Mall wrote: Next problem: border conditionality - how do I model that with the Knuth approach? At the time I add the Border/Padding start/end boxes we don't have line breaks so they really only cover the .conditionality=discard case. How do I tell the algorithm to leave enough space at

Re: Line LM, Inline LM and LAST_AREA

2005-09-06 Thread Luca Furini
Manuel Mall wrote: But if we have a long fo:inline stretching multiple lines this seem to give the wrong results from the Inline LM perspective. For example if the fo:inline finishes in the middle of a line followed by more text the Line LM will not set the LAST_AREA flag when calling

Re: e-g with padding and borders

2005-09-06 Thread Luca Furini
Manuel Mall wrote: These two paragraphs confuse me - sorry. My understanding was: discard = start/end borders/padding only at the start and end of the whole fo:inline retain = as discard plus start/end borders/padding on the start and end of every line the fo:inline spans. Sorry, you are

Re: svn commit: r279551 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/layoutmgr/inline/TextLayoutManager.java test/layoutengine/testcases/wrapper_text-transform_1.xml

2005-09-08 Thread Luca Furini
Manuel Mall wrote: this is my code after integrating your patch to add the knuth elements for line end / start border/padding for the common justify=start or end case. What I am getting now is a space at the beginning of each line break!: if (lineStartBAP != 0 || lineEndBAP != 0) {

Re: Space-resolution doesn't work

2005-09-09 Thread Luca Furini
Jeremias Maerki wrote: I'll start from scratch to come up with a better strategy of implementing these rules. I'll probably start by documenting a few cases in the Wiki and try to develop the right element list for them. After that I'll try to find out who exactly to implement everything.

Re: fo:inline bpd

2005-09-12 Thread Luca Furini
Some days ago, Manuel Mall wrote: The problem is that the Inline LM doesn't calculate the dimension of the area it is suppose to construct from the subsequence given to it by the Line LM. Instead it just assumes the dimension of the line as given to it in the LayoutContext. However, to be

Re: fo:inline bpd

2005-09-12 Thread Luca Furini
Manuel Mall wrote: yes, that is an option. What I am unsure about here is that the children, typically text areas, do not take the line spacing into account when reporting their bpd, that is the usually 10% space above and below the character. So what is the correct bpd for an fo:inline

Re: svn commit: r280520 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/TextLayoutManager.java

2005-09-13 Thread Luca Furini
I wrote: Factorized the creation of the elements in TextLM: now both getNextKE() and getChangedKE() call the same methods createElementsForASpace() and crateElementsForAWordFragment(). This should definitively solve bug 36533. Besides removing duplicated lines and inconsistencies, I hope

Re: svn commit: r280854 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/TextLayoutManager.java

2005-09-14 Thread Luca Furini
I wrote: Correct handling of the combination of hyphenation and text-align = center, left or right. At the end, I found out that this was not the same problem as bug 36533, but another bug specifically concerning the elements created to represent hyphens. I think that Manuel has been the

Re: wrap-option property

2005-09-16 Thread Luca Furini
Jeremias Maerki wrote: wrap-option is one of those few properties which work in 0.20.5 but are not yet available in FOP Trunk. Luca, what do you think how difficult it would be to implement it at least for, let's say, fo:block? I imagine it would suffice to trick the breaker into not choosing

Re: baseline-shift and KnuthInlineBoxes

2005-09-16 Thread Luca Furini
Manuel Mall wrote: if we have a baseline-shift, eg. some Xfo:inline font-size=smaller baseline-shift=super2/fo:inline ... how is that intended to be modelled with respect to the lead,height, and middle values to be stored in the created KnuthInlineBoxes for the fo:inline? I think that

Build error?

2005-09-19 Thread Luca Furini
Hi all. I'm noticing a strange problem: fop builds correctly, but then it seems it is not working at all. I'm using it from the command line under win xp, and even if I don't get any run time exception no output file is created. Launching fop with no parameters, or with wrong parameters

Re: undefined page length

2005-09-20 Thread Luca Furini
Andreas L Delmelle wrote: BTW: Is it a correct assessment that implementing this should turn out to be far simpler than fixed page-sizes? IIC, theoretically, the whole page-breaking algorithm can be ignored for indefinite page-heights. getAvailableBPD() would always return, say,

Re: Indefinite page-width / page-height

2005-09-26 Thread Luca Furini
Andreas L Delmelle wrote: Currently, I have solved this locally by creating the pageVP with the indefinite dimension set to Integer.MAX_VALUE. The only things I'm still looking for are ways to: a) retrieve the accumulated content-height/-width (or: the difference between the initial

Re: Another page-related question: page-position=last

2005-09-27 Thread Luca Furini
Jeremias Maerki wrote: It's an interesting idea. However, I suspect this will probably not be necessary. We should be able to make the breaker clever enough to handle this particular case. When the page bpd depends on the page-masters, things becomes very strange. Not only it's difficult to

Re: Another page-related question: page-position=last

2005-09-28 Thread Luca Furini
Jeremias Maerki wrote: What is the expected output? In this case it has to generate a blank page IMO. Oh, right, I did not think of an empty page! :-) The problem is with the page x of y hack that won't work like this if the last empty block ends up on the second-to-last page. [...] What

Re: Maintainability

2005-09-30 Thread Luca Furini
Peter B. West wrote: Thanks to Luca for his (perhaps entirely co-incidental) posting to the Wiki. Well, not entirely co-incidental! :-) I started writing the page some time ago, but never found the time to finish it: your message made me think I really couldn't put this off any longer, so

Re: Maintainability

2005-09-30 Thread Luca Furini
Peter B. West wrote: There seem to be some misapprehensions about what you are attempting; perhaps they are mine, so please clarify this. As I understand it, the mature, well-documented technology is the line-breaking, as in Breaking Lines Into Paragraphs. Using this model for page-breaking

Re: Knuth algorithm problem

2005-10-06 Thread Luca Furini
Jeremias Maerki wrote: I think I've just stumbled over a problem in the Knuth algorithm. I'm going to see what happens ... Regards Luca

Re: svn commit: r306656 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr: BreakingAlgorithm.java PageBreakingAlgorithm.java

2005-10-06 Thread Luca Furini
Fixing a bug reported by Jeremias affecting the handling of glue and penalty elements after a break when the algorithm restarts. Now it should be ok. A nasty little bug, anyway ... Unfortunately, I had to duplicate a few lines (a for loop looking for glue elements after a feasible break): the

Re: Inline border / padding and nested blocks

2005-10-07 Thread Luca Furini
Manuel Mall I would appreciate if you could please have a look at test case 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. If you comment everything out and uncomment the last

Re: Inline border / padding and nested blocks

2005-10-10 Thread 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

Re: Inline border / padding and nested blocks

2005-10-10 Thread 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

Re: svn commit: r321084 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java

2005-10-14 Thread Luca Furini
Fixing a ClassCastException due to the incorrect pattern of elements representing a space checked when there are inline borders and padding. The testcase inline_border_padding_block_nested_2.xml stil does not pass: there is a failing check concerning ipda. But at least there are no more

Re: DO NOT REPLY [Bug 36238] - text-align=justify doesnt' work on custom fonts

2005-10-19 Thread Luca Furini
! :-) --- Additional Comment #8 From Luca Furini 2005-10-18 12:53 Quotation from the pdf reference, version 1.6, section 5.2.2 Word spacing: Word spacing is applied to every occurrence of the single-byte character code 32 in a string when using a simple font or a composite font

Re: svn commit: r328381 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: area/inline/ layoutmgr/inline/ render/ render/pdf/ render/xml/

2005-10-26 Thread Luca Furini
Manuel Mall wrote: I have a question on this. You break in TextArea the text into words based on CharUtilities.isAnySpace. Is this guaranteed to be consistent with the breaking and adjustment calculations in TextLayoutManager? I am concerned we may be using different rules for word breaking

Re: svn commit: r328381 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: area/inline/ layoutmgr/inline/ render/ render/pdf/ render/xml/

2005-10-27 Thread Luca Furini
I wrote: Manuel Mall wrote: There is no need to expose creation of the Space/Word areas directly to TextLayoutManager either. TextArea could easily expose an addWord and an addSpace method instead of the monolithic setText. In the end it probably boils down to me arguing that the

Re: svn commit: r328381 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: area/inline/ layoutmgr/inline/ render/ render/pdf/ render/xml/

2005-10-28 Thread Luca Furini
Manuel Mall wrote: But we need to know which spaces can be adjusted, and which cannot. If we don't wont to duplicate the logic for the space recognition, the SpaceAreas must simply have a boolean value stating whether the space is adjustable, so that the renderers won't need to look at the

Re: White space handling Wiki page

2005-10-28 Thread Luca Furini
Manuel Mall wrote: Side note: FOP doesn't quite do the same internally, i.e. a character explicitly specified using fo:character.../ is handled separately from 'plain text'. If someone would write a style sheet which does a transform of every character into a fo:character / object and would

Re: Leading/trailing space removal in LineLM

2005-11-02 Thread Luca Furini
Manuel Mall wrote: So we end up with only two cases to consider: preserve white space and remove white space around a line break created by the Knuth algorithm. 1. Preserve white space: IMO in this case the space itself is actually not a break opportunity but there are now two break

Re: Leading/trailing space removal in LineLM

2005-11-02 Thread Luca Furini
Manuel Mall wrote: Luca wrote a longer response to this but my mail reader doesn't like the character set (is that topical or what?). Sorry, it looks really horrible ... still don't know what went wrong, but I won't do it again! :-) Any way at end Luca ask the question about the UAX#14

Re: Hyphenation

2005-11-15 Thread Luca Furini
Manuel Mall wrote: Hmm, just changed the value to 3000 (I think that's the value suggested in the article) and there is no change in hyphenation behaviour with the above mentioned example. That makes me a bit suspicious... I traced the beheviour of the breaking algorithm applied to the first

Re: Hyphenation

2005-11-16 Thread Luca Furini
Manuel Mall wrote: Not sure what other committers and the PMC think but as a vote on the release has started I would suggest no further changes to the codebase unless agreed? What I am saying is - by all means do the development but don't put it back into svn until after the release. Ok,

Illegal property values

2005-11-16 Thread Luca Furini
While working on the implementation of hyphenation-ladder-count, I noticed that at the moment the property system can return illegal values coming from the fo file instead of the fallback value defined by the specs. There are significant differences in wording between XSL 1.0 and 1.1: for

Re: svn commit: r345909 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/fo/flow/ src/java/org/apache/fop/layoutmgr/ src/java/org/apache/fop/layoutmgr/inline/ test/java/org/apache/fop/

2005-11-21 Thread Luca Furini
I wrote: Implementation of hyphenation-ladder-count. Just a couple of annotations: - this implementation does not store any extra information inside the nodes: the algorithm checks wheter a break is ok or not using a for loop; if you prefer, I could change this so that the number of

Re: Indent Inheritance and Collapsing Border Model

2005-12-01 Thread Luca Furini
Jeremias Maerki wrote: The first concerns indent inheritance [...] So what I'd like to do is implement the alternative behaviour as a configurable option in the FO tree. The default would still be what the specification describes (see [1]), but users would be able to set a switch that would

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

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

Re: 4.3.2 Overconstrained space-specifiers

2005-12-09 Thread Luca Furini
Jeremias Maerki wrote: You will have seen that I've been working on overconstrained documents. 5.3.4 Overconstrained Geometry is more or less implemented, so now I need to have a look at 4.3.2 which proves quite difficult to understand. At least I can't make much sense of it ATM. [...] If

Re: Kerning

2005-12-09 Thread Luca Furini
Starting from your final summary: Manuel Mall wrote: IMO FOP should limit itself to: a) Use kerning only for consecutive characters within the same fo Ok, but more on this later in this message ... b) Limit itself to the kerning information in the font Ok c) Only apply kerning if the

Re: svn commit: r349740 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/pagination/Region.java

2005-12-09 Thread Luca Furini
Relaxed validation for border and padding on region-*. I see that, at the moment, with relaxed validation FOP does no more stops with an error if a region has borders / padding, but anyway the borders and padding are not painted (and even taken into account). I was wondering whether this

Re: Hyphetation broken with last commits

2005-12-17 Thread Luca Furini
Manuel Mall wrote: Luca, why does our line breaking algorithm insist on having at least one Box in a paragraph? Is that inherent in the Knuth algorithm, i.e. can't it deal with empty paragraphs, that is paragraphs containing only Glue/Pen elements? If I remember correctly, a sequence

Off line for a week

2006-01-12 Thread Luca Furini
Hi all! I apologize for having been not very active for the last weeks, but at long last things should change: next week I will be in San Jose (California) attending a conference about digital publishing, and after that I should have some time to spend working on FOP (and I really can't wait

Re: line breaking and whitespace handling

2006-02-02 Thread Luca Furini
Manuel Mall wrote: As far as I remember our last discussion was about who should generate the Knuth element lists: The individual layout managers or the Line layout manager. You argued in favour of retaining the current system and I tended to favour the moving it up the hierarchy to the line

Re: line breaking and whitespace handling

2006-02-02 Thread Luca Furini
Manuel Mall wrote: What about using the UnresolvedElements? Just as per the block-level space resolution, each inlineLM could append at the beginning and at the end of its element list an UnresolvedElement storing its border, padding and spacing information. I don't know anything about the

Re: DO NOT REPLY [Bug 38507] - Non-breaking space in PDF title output

2006-02-06 Thread Luca Furini
Manuel Mall wrote: IMO nbsp (and any other Unicode special spaces) are outside the scope of XSL-FO whitespace handling. XSL-FO refers to whitespace as defined in XML. In XML only x#20, x#9, x#a, and x#d are considered whitespace. Therefore nbsp does not need to be considered when looking at

Re: DO NOT REPLY [Bug 38507] - Non-breaking space in PDF title output

2006-02-06 Thread Luca Furini
Manuel Mall wrote: This solves the first supposed problem (interaction between nbsp and pretty-printing spaces), but the second one is still open: what happens if we have someContentnbspspaceotherContent ? *IF* (and I'm not at all sure about this) there can be a break , then both spaces

Re: DO NOT REPLY [Bug 38507] - Non-breaking space in PDF title output

2006-02-07 Thread Luca Furini
Manuel Mall wrote: 1. The suppress-at-line-break property can be applied to all characters. I would take the position at the moment that explicit specification of the suppress-at-line-break property is not supported and we worry about it at a later stage. I would certainly argue against just

Re: white-space-collapse not working in trunk?

2006-02-14 Thread Luca Furini
(moved from fop-users as we are going into the implementation details) Manuel Mall wrote: the shorthand property white-space=pre should be used or its expanded equivalents: linefeed-treatment=preserve white-space-collapse=false white-space-treatment=preserve wrap-option=no-wrap

Re: Removing the quot;characterquot; area tree object

2006-02-27 Thread Luca Furini
Jeremias Maerki wrote: I'm considering removing the character area tree object and instead map an fo:character to a normal text area with one word child. [...] Does anybody see a problem with removing the character area tree object? No problem, it's a good idea; it could help sharing a lot

Re: letter-spacing

2006-03-01 Thread Luca Furini
Jeremias Maerki wrote: Still trying to fix my problem with letter-spacing and fixed width spaces. Do I understand that correctly that XSL-FO's view of letter-spacing is different than, say, PDF's? PDF's character spacing (PDF 1.4, 5.2.1) is designed so it advances the cursor for each (!)

Re: letter-spacing

2006-03-01 Thread Luca Furini
Jeremias Maerki wrote: The recommendation states that The algorithm for resolving the adjusted values between word spacing and letter spacing is User Agent dependent. (7.17.2 in the candidate recommendation), so I think this is not a wrong behaviour: it just assumes that word spaces have

Re: Generalized Knuth-Plass Linebreaking Algorithm

2006-04-04 Thread Luca Furini
Simon Pepping wrote: [...] See http://www.leverkruid.nl/GKPLinebreaking/index.html. Please, let me know what you think of it. I'm going to read it carefully, it seems very interesting! Regards Luca

Re: some footnotes not being displayed

2006-05-23 Thread Luca Furini
Jeremias Maerki wrote: No idea if anyone else has time to look into it. I don't think it's an easy fix, or at least easy to isolate, because footnote handling is not trivial. Having a good test case is instrumental in finding the problem quickly. Usually, this is step is 60% to fixing a bug.

Re: some footnotes not being displayed

2006-05-23 Thread Luca Furini
I've started looking at the patch attached at bug #37579, for the moment concentrating on footnotes inside lists. Concerning shortcoming 2) (from the bug comment): 2) Footnotes from list-item-body starts at the same position (from the starting edge) than the list-item-body itself and not at

Re: [GSoC] Wiki page for progress informations

2006-05-31 Thread Luca Furini
Jeremias Maerki wrote: did you already investigate how footnotes are implemented? Can you say anything about how similar the problem of footnotes is to before-floats? Just so you don't have to start from scratch while there may be something to build upon. After all, the footnotes also contain

Re: keep...=always and Knuth penalties

2006-06-19 Thread Luca Furini
Manuel Mall wrote: Yes, there is a force parameter and it seems to be always set to true for page breaking (and false for line breaking). But it doesn't seem to guarantee that breaks will be found otherwise we shouldn't get the giving up after 50 retries message. The force parameter

  1   2   >