Moving TableRowIterator to the FO Tree and Resolving Borders There

Hi all, This one is for FO tree and Layout Managers specialists. It seems to me that TableRowIterator should act during the FO-tree building rather than layout, as is currently the case. The main reason is that some validation like spanning cells that overlap can only be done once we start iterat

Re: More about the effects of the PropertyCache

Hi, Manuel Mall a écrit : > I have been following this discussion with very little attempt to > understand the intricate technical details of concurrent maps etc, but > I am wondering why we don't apply the KISS principle here? > > IIRC the original problem was that the FOP memory footprint for >

Re: Help Refactoring the Website

Hi Clay, The Web Maestro a écrit : > Hi Vincent, > > On 8/2/07, Vincent Hennebert wrote: >> Thanks for the pointers. By adding the following in skinconf.xml: >> #content { font-size: 100% } >> I managed to get normal size for the main text. I didn't commi

Re: Expected Behaviour of Nested Break-before

Sorry, attached the wrong FO file. Here it is. Vincent http://www.w3.org/1999/XSL/Format";> Before the break Text in the inner block.

Expected Behaviour of Nested Break-before

Hi, I’m suddenly all confused about the supposedly expected behaviour of breaks. Please have a look at the attached FO file and its PDF result. We get 2 pages. The break-before on the outer block and the inner block are “merged” into just one... Why? Section 4.8, “Keeps and Breaks” of XSL-FO 1

Re: AFP Output Resolution

Hi Chris, Chris Bowditch a écrit : > Vincent Hennebert wrote: > >> Well it seems that target-resolution would also be fine for AFP. >> Actually, by looking at the doc it seems that this parameter actually >> has 2 different purposes: the resolution of the output whe

Improving Keeps and Breaks

Hi all, Caution, long post ;-) I’ve been thinking about the handling of keeps and breaks in tables for a while, and it seems to me that improvements could be done in that whole area. I’ll use break-before as an example but what I’ll be saying applies to break-after and keeps as well. Currentl

Re: AFP Output Resolution

Hi Adrian, Adrian Cumiskey a écrit : > Hi, > > Currently the AFPRenderer is fixed to use a calculation against a static > final DPI_CONVERSION_FACTOR_240 to produce 240 dpi output. I've looked > at the code, and it looks fairly straight forward to introduce an extra > configuration setting which

Re: Help Refactoring the Website

Hi Clay, The Web Maestro a écrit : > On 7/31/07, Vincent Hennebert wrote: > > I've committed my changes, so the site should be re-factored. There is > likely a bunch of content in the '0.94' realm that needs updating so > it's more relevant to the current releas

Re: Drop RTF Support?

Hi Mark, Mark C. Allman a écrit : > Drop RTF with nothing to replace it, e.g., ODF? I'd rather not. > > Swap out RTF with, say, ODF? Sounds great to me. > > I'd even volunteer some time to help with development. I seem to > remember something about Java ;-] Thanks for your offer to help!

Re: Drop RTF Support?

Hi, Jeremias Maerki a écrit : > Such a move would have to be well-documented because some people could > (or probably will anyway) be upset when they upgrade and RTF just stops > working until they add fop-sandbox.jar. I'm sure there are a lot of > people perfectly happy with what the RTF handler

Drop RTF Support?

Hi, There have been various questions on fop-user recently regarding the RTF output of FOP. Personally I’m incapable of helping in this area, and also most unwilling to. Tell me if I’m wrong, but I suspect that in the current team there is about one person who could help / modify the code, and wh

Update the status.xml file (was: Re: svn commit: r561280 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/afp/AFPRenderer.java status.xml)

Taking advantage of this to drop a note to developers (including myself...). > Author: jeremias > Modified: > xmlgraphics/fop/trunk/status.xml Please try and think of updating this file whenever you commit a notable modification, that’s very important for tracking changes and seeing improveme

Re: Help Refactoring the Website

Hi Clay, Thanks for chiming in! It seems we are somewhat duplicating our efforts here. I already removed the 0.20.5 tab and added a new one for 0.94. Look at the 0.94 branch of the svn repository. I prefer to work in the branch so that the trunk stil reflects the current site, and we can re-gener

Help Refactoring the Website

Hi all, The 0.94 version of FOP is basically ready to be released. The poll on fop-user gave interesting results, although not applicable to the next release. What about creating a wiki page summarizing those user wishes? Users could then maintain it by themselves. Andreas, would you be willing to

Re: Fonts in JAR files

Hi Max, Max Berger a écrit : > Vincent, > > Vincent Hennebert schrieb: >> Your idea of using manifest.xml looks fine. A quick Google search didn't >> give me any result regarding a standard way of bundling fonts with Java >> apps. It looks like you did also searc

Re: Fonts in JAR files

Hi Max, Some general comments. Basically I agree with Andreas and think this would be a good addition. Your idea of using manifest.xml looks fine. A quick Google search didn't give me any result regarding a standard way of bundling fonts with Java apps. It looks like you did also search for that

Re: Bounty for auto table layout?

Hi Jens, Jens Bannmann a écrit : > Vincent Hennebert wrote: >> Question is, also, how to advertise the thing. Would the fop-user >> mailing list be enough to attract donators? > > From a quick search, it doesn't seem that the topic was brought up > previously on t

Re: Subversion update problems

Hi Adrian, Adrian Cumiskey a écrit : > Hi all, > > I realise this isn't a FOP question but when I try to update my trunk > sandbox with subversion I get "svn: Delta source ended unexpectedly". > Does anyone else experiencing this problem? > > svn up -N (non-recursive update works fine) > > and

Re: font selection by character

Hi Andreas, My 2 cents on this, as I have a rather limited understanding of this area. Andreas L Delmelle a écrit : > org.apache.fop.fonts.Font contains a fontSize member. I would like to > see this separated from the Font instance somehow. Instead of fetching a > Font corresponding to given tri

Word Joiner and ZWNBSP (Re: svn commit: r557219 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/layoutmgr/inline/TextLayoutManager.java src/java/org/apache/fop/util/CharUtilities.java status.xml

Hi Manuel, > Author: manuel > Date: Wed Jul 18 03:40:12 2007 > New Revision: 557219 > > URL: http://svn.apache.org/viewvc?view=rev&rev=557219 > Log: > Fixed incomplete support for Unicode word joiners Can you please have a look at the attached FO file and the resulting PDF I get? There's a word

Using svnmerge.py (Re: svn commit: r558281 - /xmlgraphics/fop/branches/fop-0_94/)

Hi all, > Author: vhennebert > Date: Sat Jul 21 02:50:32 2007 > New Revision: 558281 > > URL: http://svn.apache.org/viewvc?view=rev&rev=558281 > Log: > Initialize merge tracking via "svnmerge" from the Trunk > (for applying to the 0.94 branch the applicable changes in the Trunk) > > Modified: >

Re: svn commit: r557337 [1/8] - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: apps/ area/ area/inline/ cli/ datatypes/ fo/ fo/expr/ fo/extensions/ fo/extensions/destination/ fo/extensions/svg/ fo

Well done, Andreas! > In the process, some oddities that caught my eye in the javadocs were > corrected as well. On the other hand, I do not completely rule out that > new oddities have been introduced (the diff being +16000 lines), so keep > your eyes open for those... IMO it's perfectly fine t

Re: Bounty for auto table layout?

Hi, I second that, a good idea for sure! Regarding how this may be done within the ASF, that's probably a question we can ask on [EMAIL PROTECTED] Maybe the ASF itself can serve as the SPP platform? I think it's worth making a poll on fop-user to see how many users would be ready to participate

Re: Remove Useless Comments

Hi Andreas, Andreas L Delmelle a écrit : > On Jul 14, 2007, at 15:59, Vincent Hennebert wrote: > > Vincent > >> Andreas L Delmelle a écrit : >>> >>> Tested locally, and is OK here. If you'd like, I can run a sanity diff >>> later tonight, and

Re: svn commit: r556112 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fonts/truetype/TTFFile.java util/IntMap.java

Hi, Manuel Mall a écrit : > On Wednesday 18 July 2007 02:58, Andreas L Delmelle wrote: > Interestingly Java 1.5 has added the Integer.valueOf(int) method with > the following comment: Flyweight pattern. That's what I was looking for before replying to Andreas' commit, and I was surprised to not

Re: FontSources

Hi Adrian, I'm not really a specialist of the font handling stuff in FOP, but having worked a bit in this area I can drop a few ideas (and ask a few naive questions), in the hope they will be useful. > In the process of looking at this bug > (http://issues.apache.org/bugzilla/show_bug.cgi?id=428

Re: svn commit: r556112 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fonts/truetype/TTFFile.java util/IntMap.java

Hi Andreas, > Author: adelmelle > Date: Fri Jul 13 12:21:03 2007 > New Revision: 556112 > > URL: http://svn.apache.org/viewvc?view=rev&rev=556112 > Log: > Addition of a general-purpose int-to-int map to replace Integer-to-Integer > HashMaps + first usage in TTFFile > > Added: > xmlgraphics/

Re: Remove Useless Comments

Andreas L Delmelle a écrit : > On Jul 14, 2007, at 13:27, Vincent Hennebert wrote: >> J.Pietschmann a écrit : >>> I think of JavaDoc as a sort of compile time feature. I don't think >>> there's still a reason to generate the JavaDocs with a JDK version >>

Re: Plan for the 0.94 release

Hi Andreas, Andreas L Delmelle a écrit : >> I propose the following plan: >> - make a list of patches/bugs that we would like to apply/fix before >> releasing. Here everyone can help, even non-committers ;-) Once the >> list is done we will see how many of them we can handle. > > Shall I pos

Re: Remove Useless Comments

J.Pietschmann a écrit : > Jeremias Maerki wrote: >> Yes, inheritDoc would be the right way, as long as we're on Java 1.4.2 >> and later (feature not available in 1.3, severly buggy in 1.4.0/1.4.1. I >> would have switched a long time ago if we weren't still on 1.3. > > I think of JavaDoc as a sort

Re: Plan for the 0.94 release

Jeremias Maerki a écrit : > On 13.07.2007 15:45:01 Vincent Hennebert wrote: > >> Speaking of branches, I noticed that there are many (very) old branches >> on Subversion. What about removing them? > > -1. If you want to clean up, please create a subdirectory "old-

Plan for the 0.94 release

Hi all, I'll soon start the release process for XML Graphics Commons. There's not much to do there, apart from updating the website content. Meanwhile I'd like to enter some kind of freezing phase in the FOP area. That is, mainly, avoid to perform too big changes which might introduce instabilitie

Remove Useless Comments [Re: svn commit: r555684 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java]

Hi, Nothing related with (and against) the original change, but I take this one as an opportunity to launch the discussion. I've been having this in my head for a while. > Modified: > > xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java > > Modified: > xm

Re: junit-layout-standard test broken

Adrian Cumiskey a écrit : > The junit-layout-standard target seems to broken on trunk... My bad, sorry. I didn't think of table cells with content of zero length, which was the root of the problem... I've committed a temporary hack as I'm in the process of heavily changing this part of the code. L

Re: DO NOT REPLY [Bug 42845] - Printing error. Prints charater+1.

Hi Chris, I fully agree with you. Moreover I think the website refactoring should be done when releasing FOP 0.94, and that's where I call for help. We would remove the 0.20.5 tab and replace it with a "upgrading from earlier versions" section. Once 0.94 is out we would remove the 0.20.5 entry fro

Re: FOP 0.94

Hi Max, Max Berger a écrit : > Vincent, > > I would love to have Bug 42785 ( patch to support baseline-shift ) > applied before the release, because then I could release a new plugin > for the new version. I've read your comment, and I will check with the > spec which options I have to improve th

FOP 0.94

Hi guys, Title says it all. FOP 0.93 was released the 9th of January. I think it's time to release the next version, as many bugs have been corrected and many exciting new features added. Anyone against a new release? I'd volunteer to deal with all the release process... unless someone volunteer

Re: Row backgrounds vs table background

hat the user would expect, but doesn't really make sense IMO. Anyway, another candidate request for clarification to xsl-editors@ I guess... Vincent > On 29.06.2007 11:04:13 Vincent Hennebert wrote: >> Guys, >> >> I believe there's a bug in the handling of table- an

Collapsing Borders, Spans, Background in Border Segment

Hi all, Another question regarding backgrounds. See the attached FO file and the resulting PDF. Cell 1.1 is spanning over 2 rows. Its border-right is composed of 2 segments, one thicker and one thinner. For the latter, the gap is currently filled with the table's background. Question is: shouldn'

Two New Active FOP Contributors

Hi, On behalf of the XML Graphics PMC I am pleased to announce that we have two new active contributors to FOP: - Max Berger - Adrian Cumiskey Many thanks for your contributions, and we hope that you will continue! Vincent

Re: DO NOT REPLY [Bug 42476] - [PATCH] Bugfix for XMLReader: Support for other ImageReaders

Hi Max, > --- Additional Comments From [EMAIL PROTECTED] 2007-05-23 02:07 --- > Created an attachment (id=20244) > --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20244&action=view) > Yet another try I was about to hit return after having entered the svn commit command... when

Re: Suggestion: refactoring property access in the FO tree?

Hi Richard, Thanks for your contribution. I'll try to have a look ASAP but I'm a bit in a hurry currently. Stay tuned. Vincent richardw geoquip-rnd demon co uk a écrit : > Vincent Hennebert writes: > > I fully agree. Good design should not be sacrificed for efficiency. &

ApacheCon approaching

Hi guys, So the ApacheCon is quickly approaching... what will we be doing? Said they would be present: Andreas, Jeremias, Simon, Me (did I forget anyone?). Some things we could do: - meet people - cleanup the bug database - knowledge transfer: area tree, layout, renderers - discuss about the arc

Re: svn commit: r531799 - /xmlgraphics/fop/trunk/test/layoutengine/standard-testcases/table_border-collapse_collapse_nrnc.xml

Hi, This is probably for Jeremias... See the border between cell 2.1 and cell 3.1 in the second table of this testcase. The area tree is correct, but the painting is weird, there is some blank area between the two border-halves. This occurs in PDF, PS and AWT outputs. This is more for the record,

Re: svn commit: r530727 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/fo/flow/Table.java status.xml

Hi Jeremias, Jeremias Maerki a écrit : > Great news, Vincent! Good stuff! Thanks! Although there is still some work to do. > Of course, I had to try it out immediately and it looks promising. Still, > I've got a few points for you to look into: > - Please reenable the two test cases for border

SpaceHandling[Break]Position, associated LayoutManager and AreaAdditionUtil

Hi, Is there any reason why SpaceHandling[Break]Position elements created by SpaceResolver don't have any LayoutManager associated to them? As a result, in AreaAdditionUtil.addAreas, if the first Position element is a SpaceHandling[Break]Position, then the position list is not iterated over to add

Re: LayoutEngineTestSuite: disabled and start-with properties

Vincent Hennebert a écrit : > Guys, > > When running the layoutengine testsuite, it is possible to use several > properties to select the testcases you want to run. As a reminder > everything is explained here: > http://wiki.apache.org/xmlgraphics-fop/HowToCreateLayoutEngine

Re: svn commit: r529507 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/pdf/DestinationComparator.java

Hi Paul, Paul Vinkenoog a écrit : > Hello Vincent, > >> +public int compare (Object obj1, Object obj2) { >> +if (obj1 instanceof PDFDestination && obj2 instanceof >> PDFDestination) { >> +PDFDestination dest1 = (PDFDestination)obj1; >> +PDFDestination dest2 = (PDFDest

Re: svn commit: r525078 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/area/ src/java/org/apache/fop/fo/extensions/destination/ src/java/org/apache/fop/pdf/

Hi Jay, Jay Bryant a écrit : >> - if your modifications are non-trivial (as is the case here), it's very >> important to add a note about them in the status.xml file. The content >> of this file appears on the following web page: >> http://xmlgraphics.apache.org/fop/changes.html > > Where? In

One week offline

Offering some fresh air to my brain ;-) Cheers, Vincent

Border- and padding-conditionality and fences

if borders and padding should actually be discarded or not. While this interpretation makes sense and would match users' expectations, I'm not sure if it is really intended by the Recommendation. So could you please provide a clarification on this subject? Thanks, Vincent Henn

Clarification for tables: grid units, border-resolution and breaks

x27;t think it makes much sense to set the break-before and break-after properties on fo:table-row and children of fo:table-cell which are themselves children of fo:table-header and fo:table-footer elements. It might be helpful to explicitely state that in the descriptions of break-before and br

Re: svn commit: r525078 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/area/ src/java/org/apache/fop/fo/extensions/destination/ src/java/org/apache/fop/pdf/

Hi Jay, First, congratulations for this new feature! This is a great addition to FOP. A few remarks about your commit: - I suggest you to install and setup checkstyle if you haven't done yet; - don't forget to add the ASF headers (checkstyle will notify you about that, BTW) and set the "svn:key

Re: Suggestion: refactoring property access in the FO tree?

Hi Andreas, Andreas L Delmelle a écrit : > On Mar 30, 2007, at 11:21, Vincent Hennebert wrote: >>> In ancient times, each FO had a full PropertyList, so the properties >>> could be queried via a generic get(PROPERTY_ID) accessor that was simply >>> a proxy to the Pr

Re: Footnotes in the float branch

oats Luca Furini a écrit : > Vincent Hennebert wrote: > >> Hi Luca, > > Hi! > >> I had a look at your patch and have several comments: >> - I see you re-enabled the noBreakBetween method; I don't think it's >> a good solution because it artific

LayoutEngineTestSuite: disabled and start-with properties

Guys, When running the layoutengine testsuite, it is possible to use several properties to select the testcases you want to run. As a reminder everything is explained here: http://wiki.apache.org/xmlgraphics-fop/HowToCreateLayoutEngineTests You can exclude the disabled testcases to be run by usin

Re: Suggestion: refactoring property access in the FO tree?

Hi Andreas, I have little knowledge of the FO tree construction, so I'll perhaps make naive questions and remarks. I write them in the hope they will trigger further thoughts. Andreas L Delmelle a écrit : > > Hi, > > Just an idea that popped in my head. I was thinking of the access to a > FONod

Re: More on border and padding conditionalities

Hi Andreas, Andreas L Delmelle a écrit : > I'm wondering if your confusion is not caused by the fact that > space-properties can also be specified as conditional, and there is a > very subtle difference between conditionality in the cases of: > 1) a space-specifier: "a compound datatype whose com

Re: Percentages in CommonAbsolutePosition?

Hi Paul, So you wanna join the game? ;-) Paul Vinkenoog a écrit : > The (1.1) spec says that if the positioning is... > > - absolute: > the positions are taken with respect to the nearest ancestor > reference area; > > - fixed: > the positions are taken with respect to the page viewport

Re: More on border and padding conditionalities

Hi Andreas, Andreas L Delmelle a écrit : > On Mar 27, 2007, at 10:47, Vincent Hennebert wrote: > >> Andreas L Delmelle a écrit : >>> On Mar 26, 2007, at 16:48, Vincent Hennebert wrote: > >>>> I'm having a lot of fun playing with border and padding &

Re: Footnotes in the float branch

Grmblmblm... and the attached fo file, of course... Vincent Vincent Hennebert a écrit : > Hi Luca, > > Luca Furini a écrit : >> Hi all >> >> I recently had the time (and the pleasure) to look at before-float >> implementation branch, and I played a bit with it

Re: Footnotes in the float branch

Hi Luca, Luca Furini a écrit : > Hi all > > I recently had the time (and the pleasure) to look at before-float > implementation branch, and I played a bit with it. > > I focused on the handling of footnotes, as I noticed that sometimes they > were placed on a page following their citations without

Re: More on border and padding conditionalities

Hi Andreas, Andreas L Delmelle a écrit : > On Mar 26, 2007, at 16:48, Vincent Hennebert wrote: > > Hi Vincent, > >> I'm having a lot of fun playing with border and padding >> conditionalities... > >> I think the padding should actually not be discarded

Re: Percentages in CommonAbsolutePosition?

Hi Andreas, Andreas L Delmelle a écrit : > On Mar 26, 2007, at 11:47, [EMAIL PROTECTED] wrote: > >>> If I understand you correctly, what you're saying is that if the fixed >>> positioned block's nearest ref-area is not initially visible, then the >>> top/left/etc. properties should be taken WRT t

More on border and padding conditionalities

Hi all, I'm having a lot of fun playing with border and padding conditionalities... What do you think of the attached fo file (resulting pdf also attached)? I think the padding should actually not be discarded on the second page. It would if the corresponding edge were a leading edge in the regio

Re: Border conditionalities and collapsing-border model, breaks on header/footer

Hi, Thanks for your inputs, Andreas and Jeremias. The whole thing suddenly makes sense when you think in terms of area tree instead of fo tree... Still, I think it's not obvious by reading the spec and I'll probably ask for clarification on [EMAIL PROTECTED] And there is a remaining question rai

Re: Percentages in CommonAbsolutePosition?

Hi Andreas, Andreas L Delmelle a écrit : > On Mar 23, 2007, at 11:22, Vincent Hennebert wrote: > >> Thanks for your perseverance ;-) > > You're welcome. :o) I'm sure we will manage! >>> >>> If the nearest ancestor ref-area is not immediately v

Re: Border conditionalities and collapsing-border model, breaks on header/footer

Jeremias Maerki a écrit : > On 23.03.2007 15:44:57 Vincent Hennebert wrote: >> Guys, >> >> I've again stumbled upon uncertainties regarding the handling of >> conditional borders in the collapsing-border model, and breaks inside >> headers/footers. I

Border conditionalities and collapsing-border model, breaks on header/footer

Guys, I've again stumbled upon uncertainties regarding the handling of conditional borders in the collapsing-border model, and breaks inside headers/footers. I'd like to have your opinions on these: Table headers and footers: Headers and footers are generated only once, and replicated on each pa

Re: svn commit: r521640 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/layoutmgr/table/ColumnSetup.java test/layoutengine/standard-testcases/table-column_missing.xml

se. Something like that, yes. We would then have two methods of iterating over tables: one fast, memory-efficient relying on columns specifications, and one slow, memory-consuming parsing the entire table before doing anything else. Vincent > > On 23.03.2007 12:30:02 Vincent Hennebert wro

Re: svn commit: r521640 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/layoutmgr/table/ColumnSetup.java test/layoutengine/standard-testcases/table-column_missing.xml

Jeremias, > Author: jeremias > Date: Fri Mar 23 02:19:04 2007 > New Revision: 521640 > > URL: http://svn.apache.org/viewvc?view=rev&rev=521640 > Log: > Avoid an IndexOutOfBoundsException when more columns are used than are > specified even though this is illegal with fixed table layout. What ab

Re: SpaceResolver usage

Hi, Jeremias Maerki a écrit : > On 22.03.2007 11:41:28 Vincent Hennebert wrote: >> Hi, >> This raises the question as to how retained borders and paddings are >> handled: their widths will count in the penalty width of resolved break >> elements. How are borders fr

Re: Percentages in CommonAbsolutePosition?

Hi Andreas, Thanks for your perseverance ;-) Andreas L Delmelle a écrit : > On Mar 22, 2007, at 10:05, Vincent Hennebert wrote: > > Hi Vincent, > >> >> Well, that's still unclear. The area should be placed like in the >> "absolute" model, plus m

SpaceResolver usage

Hi, A small question: am I true that the element list passed as parameter of the SpaceResolver.resolveElementList method should be delimited by reference areas? That is: as there is a fence before (and after) a reference area, there will never be stacking constraints crossing ref-areas's boundarie

Re: Percentages in CommonAbsolutePosition?

Jeremias Maerki a écrit : > On 21.03.2007 21:22:04 Andreas L Delmelle wrote: >> On Mar 21, 2007, at 10:42, Vincent Hennebert wrote: >> >>>> >>>> Whatever follows in that second definition is irrelevant wrt >>>> determining the base for percent

Re: Percentages in CommonAbsolutePosition?

Hi Andreas, [EMAIL PROTECTED] a écrit : >> - Oorspronkelijk bericht - >> Van: Chris Bowditch [mailto:[EMAIL PROTECTED] >> > >> AFAICT, I don't think you've got everything nailed down here. As Vincent >> already mentioned the ancestor reference area could change depending on >> the value

Re: Percentages in CommonAbsolutePosition?

Hi, Manuel Mall a écrit : > On Tuesday 20 March 2007 04:10, Andreas L Delmelle wrote: >> A fix for the left-percentage is setting the PercentBase on the >> PropertyMaker for "left" to LengthBase.CONTAINING_BLOCK_WIDTH in >> FOPropertyMapping.createAbsolutePositionProperties(). >> Although I'm not

Unit testing using logs

Hi, Again I'd like to share my thoughts. I've been looking for a while for a means to unit-test the layout code. There are two difficulties I think: - re-creating the necessary LayoutManager structure. While it would be great to be able to create only the necessary LMs (e.g., TableLM and its c

Re: DO NOT REPLY [Bug 41860] - FOP crash on fixed-layout table with increasing number of cells/row

Hi, [Andreas] > This should indeed be handled better, but your FO is actually very dubious... > In fixed-layout, the number of columns and their respective widths are > ultimately determined based on > the cells in the first row. There is no obligation for an implementation of > XSL-FO to even

Re: AddAreas in RowPainter

Hi Jeremias, Thanks for your answers. Jeremias Maerki a écrit : > On 17.03.2007 01:37:16 Vincent Hennebert wrote: >> Hi, >> >> There are things unclear to me in the addAreasAndFlushRow method of the >> RowPainter class. I hope someone can shed some light: > > I

AddAreas in RowPainter

Hi, There are things unclear to me in the addAreasAndFlushRow method of the RowPainter class. I hope someone can shed some light: - why is a Map used to store y-offsets of rows? That seems to indicate that rows are not added in a sequential order, or that there could be hole between them, whic

Re: How could I change vertical alignment of list item bullet? [was in fop-user]

Hi Manuel, Manuel Mall a écrit : > On Tuesday 13 March 2007 17:50, Vincent Hennebert wrote: >> [Moving to fop-dev as we're going to speak about implementation >> details] >> >> Andrejus Chaliapinas a écrit : >>> Hi Jeremias, >>> >>>&g

Re: How could I change vertical alignment of list item bullet? [was in fop-user]

[Moving to fop-dev as we're going to speak about implementation details] Andrejus Chaliapinas a écrit : > Hi Jeremias, > >> I've just checked since I was curious. It's already in 0.90. Seems to >> have to do with font metrics. Take a look at the Area Tree XML. The >> label has a BPD of 18936 whil

Re: Position, Leaf/NonLeafPosition, wrapping positions

Andreas, First, many thanks for your explanations! Some comments below. Andreas L Delmelle a écrit : > On Mar 8, 2007, at 20:15, Andreas L Delmelle wrote: > > Hi Vincent, > >> On Mar 8, 2007, at 18:29, Vincent Hennebert wrote: >> >>> >>> >>>

Re: Position, Leaf/NonLeafPosition, wrapping positions

that picture represent the current code? If not, what is missing/wrong, apart from the many details relevant to each particular LM? Does that make sense? Thanks, Vincent Jeremias Maerki a écrit : > On 07.03.2007 15:28:37 Andreas L Delmelle wrote: >> On Mar 7, 2007, at 09:07, Vincent H

Position, Leaf/NonLeafPosition, wrapping positions

Hi, I have some questions regarding the handling of Position elements. I'm not familiar with that part of the code yet, and as there is little or no javadoc for those it's a bit difficult to guess their purposes just by looking at the code. What's the purpose of a LeafPosition? Of a NonLeafPositio

Re: svn commit: r512266 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/table/TableStepper.java

Jeremias Maerki a écrit : > Vincent, > > can I please ask you to put code guards (if (log.isDebugEnabled())...) > around debug and trace log statements? This avoids unnecessary string > concatenation if the respective log level is diabled. > See also: http://jakarta.apache.org/commons/logging/guid

Re: ApacheCon EU

Hi Andreas, Andreas L Delmelle a écrit : > > Anyone here going to Amsterdam (or: 'staying there' would be more > fitting for Simon) in May? Yes I should be going there, just waiting for the special registration code providing a discount for Apache committers. > I can make it only on the openin

Re: svn commit: r507449 - in /xmlgraphics/fop/trunk/test: java/org/apache/fop/layoutmgr/table/ layoutmgr/table/

Christian Geisert a écrit : > [EMAIL PROTECTED] schrieb: >> Author: vhennebert >> Date: Wed Feb 14 01:32:03 2007 >> New Revision: 507449 >> >> URL: http://svn.apache.org/viewvc?view=rev&rev=507449 >> Log: >> I thought the svn:eol-style and svn:keywords properties were automatically >> set on java

Re: FO snippets for unit testing

Andreas L Delmelle a écrit : > On Feb 12, 2007, at 20:02, Andreas L Delmelle wrote: > >> On Feb 12, 2007, at 18:00, Vincent Hennebert wrote: >>> So my question is: is there a possibility of creating a tree of FObj >>> instances from a corresponding FO fragment, and u

Officially supported version of the Recommendation

Guys, It may be worth clarifying which version of XSL-FO we officially support, now that 1.1 has reached the status of a recommendation. I guess we can now take it as a reference, since it clears some uncertainties of the 1.0 version. I've just noticed that I'm myself still looking at the 1.0 copy

FO snippets for unit testing

Hi All, I think the codebase is seriously lacking of unit tests, which makes refactoring a bit hazardous. Of course there is the wonderful layoutengine testsuite that allows to check if a XSL-FO file is rendered as expected (BTW, I don't remember who introduced this feature, but a huge thanks to t

Re: DO NOT REPLY [Bug 41514] - [PATCH] Strict url validation of user config

Hi Adrian, Adrian Cumiskey a écrit : > Vincent Hennebert wrote: >> >> Yes, the patch doesn't seem to break anything. We could even go a bit >> further: the cfg parameter is no longer used in the >> FOUserAgent.configure() method, it might be removed. Also, would

Re: DO NOT REPLY [Bug 41514] - [PATCH] Strict url validation of user config

> 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/bu

Re: DO NOT REPLY [Bug 41514] - [PATCH] Strict url validation of user config

Hi Adrian, Adrian Cumiskey a écrit : >> - we may discuss about the interest of a separate/yet another parameter >> for validating the config file. I can understand both points of vue >> and, actually, I don't really care of which is chosen. That said, >> I think validation of the config fil

Re: DO NOT REPLY [Bug 41514] - [PATCH] Strict url validation of user config

Hi Adrian, Sorry for the delay. I've had a look at your patch. First of all, thanks for taking care of this. Strong validation of user config files is a great step towards user-friendliness. Thanks also for thinking of documentation and testcases! I have a few comments, some of which are open for

Re: Increase in activity?

Chris Bowditch a écrit : > Jeremias Maerki wrote: > >> Do I have a slightly distorted perception or do we currently see an >> increase in activity, even patches, following the 0.93 release? > > Hi Jeremias, > > yes I think there has been a increase in both user and development > activity in the

Re: Before floats + footnotes

Luca Furini a écrit : > I agree that, in a sense, the "error" is in the fo file, defining a > fixed-height footnote separator that does not fit well the page; with an > heigth of 12 pt, all would be ok. In alternative, it could be defined > using a min-opt-max line height or space-*, allowing for s

Re: Before floats + footnotes

Hi Luca, Luca Furini a écrit : > Hi all! > > At long last, I'm finally allowed some time to look at the float branch > and ... wow! Really impressive, a great lot of good work! Well, thanks! > In order to apologize for my long absence :-) , I'm trying to see what's > wrong with the failing tes

<    3   4   5   6   7   8   9   10   >