Re: Bounty for auto table layout?
Andreas L Delmelle wrote: On Jul 20, 2007, at 14:08, Andrejus Chaliapinas wrote: Hi Hi Thought I'd chime in on this one as well... First off: I agree with the general sentiment that this is a very interesting initiative! That said, as a note of caution, I do wonder whether the motivation (with or without the bounty) is enough by itself to make it happen. I've recently also been looking in the direction of the patch in bugzilla 40271, but I'm under the impression that certain other things need to happen first before a decent auto-layout implementation becomes a feasible project... Not Patrick's fault, --he was motivated-- but maybe such an enterprise was too complex to take on as a one-man GSoC project. Even if it didn't immediately succeed, it did give us a better impression of other changes that could reduce the complexity drastically. I am still motivated in participating in this feature. As you said there are things that need to happen, or at least in my case things that need to be understood before being able to do a decent auto-layout implementation. I remember the main difficulty I had was to get information (i.e. the width) up the tree in order to compute the proper width of each column. Moreover a mechanism would have to be devised to avoid performing some operations twice (the first pass to determine the optimal width and the second one to render the table). (...) Some time ago I've tried to dig a little into those Layouts techniques, but quickly found that it's not the thing I could enhance myself easily (though it was some initial information provided by Jeremias and Simon and maybe others, but still not easy to understand without UML graphs of pieces interaction), so stayed mostly with work on various XSL/XML parts for my projects needs and left those FO things for real experts :). What helped me a lot in understanding certain parts of the overall processing were not necessarily words or graphs, but mainly random debug sessions. Stroll through the code, place a few breakpoints in the parts of the code that interest you, debug the process, have a look at the call stacks, step further to see which other methods are called afterwards to get a hang of how the objects and the logic fit together, and which methods are called at what point in the process... Not perfect, but very educational. :-) I completely agree. I remember spending hours and hours just figuring out which methods are called at lower levels of the layout engine and how the information works its way back up the tree. Cheers Andreas Regards, Patrick
Re: ApacheCon US
Hi Jeremias and everyone, I did the presentation on Apache FOP Thursday morning. All went well, I had about 20 people in a regular size room. People were interested in the presentation overall, but what they were most interested in is the entire tool chain from XML to PDF. When I showed them an example of some work I have done using Docbook XML and output it in customized XHTML and PDF there eyes widened. That really spiked their interest ! Little anecdote, I highly recommended Definitive XSL-FO and a person actually bought it online during the presentation. Wow ! I've seen Carsten Ziegeler from Cocoon, and met with Ferdinand Soethe from the Apache Forrest project. I found ApacheCon to be very well organized in general. The weather here in Austin is great. I'll be heading back to Montreal this afternoon. Regards to all, Patrick Paul Jeremias Maerki wrote: Patrick, how did the FOP talk go? Anyone else at ApacheCon right now? Jeremias Maerki __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Generating Javadoc FOP documentation
Hi Nicol: ant -projecthelp This will give you help about the commands. So for javadoc do ant javadocs. HTH, Patrick Nicol Bolas wrote: How do you go about generating the Javadoc FOP documentation?
Re: Q: Line-layout - separating element-list creation / line-breaking
Andreas L Delmelle wrote: Hi all, Hello everyone ;-) I've been doing some thinking myself about the separation between element-list creation and actual line-breaking, and went wandering through the related sources. Just checking here if my initial estimates are correct. At first glance, a possible separation seems already prepared in some way: LineLM.createLineBreaks() is already a separate method, so could in theory be called independently from LineLM.collectInlineKnuthElements () --maybe depending on a boolean switch passed into LineLM.getNextKnuthElements() (as a first step?) The only gotcha seems to be the TODO on lines 580-582 in LineLayoutManager, where the 'available IPD' is passed into collectInlineKnuthElements(). Following the path of this variable, it is afterwards only used to create a lineFiller to use for the first/last lines in the paragraph, only in case of non-centered alignment. The min/opt/max values of the filler are used to calculate the width for the first/last penalties and/or glues added in Paragraph.startSequence() / .endSequence(). That's the only influence that 'available IPD' has on the created element list. The only elements invalidated by a later IPD change seem to be those start- or end-of-paragraph elements, but they could be either replaced or adjusted by the breaker. Provided, of course, that they are made distinguishable from the other elements --either by marking them, or providing accessors for Paragraph.ignoreAtStart and .ignoreAtEnd (?) If I see it correctly, what we want to go towards is a two-phased approach: 1) getBaseKnuthElements() (or: collectKnuthElements()) the lower level LM constructs its base element list completely, and passes it up to the ancestor LM for inspection and detection of content-width constraints (and other constraints, like forced breaks and keeps, widows/orphans) 2) processElementList(from, to, context, alignment) (would correspond to the current getNextKnuthElements(), if called with 'from' equal to zero, and 'to' equal to list.size()) the higher level LM issues repeated requests to the lower level LM to return element sublists from A to B, but now including the line-breaks, when given certain ipd- and alignment constraints Why not keep getNextKnuthElements() wich does the line breaking depending on a boolean switch ? Then depending on wether the element list already exists, the (modified) collectKnuthElements() method is called. This is my perspective for the auto-table layout, since I am implementing a new LayoutManager method called determineMinMaxTextWidths() which returns an object containing the two values needed to calculate optimum column widths. These values will go up the hierarchy up to the TableLM where the optimal column widths will be determined. So no need to return the actual element lists, right ? and it's step 2) that offers a possibility to restart the breaking from one arbitrary element up to another. The start(from) and end(to) element for the sublists could be estimated, based on the content-width, line-height and the context's ipd/bpd-constraints: if minimum-line-height X allows L lines to be stacked in BP direction = room for a maximum of (L * available-IPD) in unbroken content-width If the actual last element that fits in the context turns out not to be the last element of the sublist, a pointer should be kept to the first element in the remainder of the processed list for which baseList.indexOf() does not return -1, in order to obtain the start element for the next call. As such, before making each 'processElementList(from, to, ...)' request, the higher level LM gets a chance to update the layout- context if there is a change in available IPD --for instance due to a (deferred) side-float, or a change in page-master and/or reference- orientation. The breaker, on the other hand, could suspend or interrupt the process, for instance upon encountering a start-float, so that the next iteration starts with the float's element list (= finish current line, return control to the higher level LM, treat the float, if necessary update layout-context's ipd, and resume the breaking in the updated context) If the float fits on the page, then this should offer a reasonable guarantee that it will end up starting on the line following the one that contains its anchor. Am I making things too simple? Too complicated? :/ Andreas Patrick
Re: Q: Line-layout - separating element-list creation / line-breaking
Andreas L Delmelle wrote: On Aug 23, 2006, at 17:44, Patrick Paul wrote: snip / Why not keep getNextKnuthElements() wich does the line breaking depending on a boolean switch ? Then depending on wether the element list already exists, the (modified) collectKnuthElements() method is called. FTM, such a boolean switch would probably be the wisest move. Not changing too much at once. This is my perspective for the auto-table layout, since I am implementing a new LayoutManager method called determineMinMaxTextWidths() which returns an object containing the two values needed to calculate optimum column widths. These values will go up the hierarchy up to the TableLM where the optimal column widths will be determined. So no need to return the actual element lists, right ? Correct. To determine the minimum column-widths, you don't actually need the element lists themselves, only the width of widest piece of unbreakable content in the list. As a nit, the suggested name determineMinMaxTextWidths() is maybe a bit misleading, since it is not merely text we're dealing with (could also be images... = determineMinMaxContentWidth()?) You are right. Thanks for the suggestion. I would even say that determine is misleading since the min and max content widths are calculated when getNextKnuthElements is called. So it maybe it would be better to name it getMinMaxContentWidth() ? Maybe I shouldn't be calculating the min and max content widths while element creation is done ? Cheers, Andreas Patrick
Re: Q: Line-layout - separating element-list creation / line-breaking
Andreas L Delmelle wrote: On Aug 23, 2006, at 20:16, Patrick Paul wrote: snip / You are right. Thanks for the suggestion. I would even say that determine is misleading since the min and max content widths are calculated when getNextKnuthElements is called. So it maybe it would be better to name it getMinMaxContentWidth() ? That would be fine, if the method's return type reflects this. It returns an object that I called MinMax. This object has to accessors: int getMin() and int getMax(). Maybe I shouldn't be calculating the min and max content widths while element creation is done ? Not sure what you mean here: the elements need to be created to be able to determine how large your minimum-width is, so your min/max calculation needs to be performed in between the element creation and the start of the actual breaking... Yes I agree. I am actually doing this WHILE the elements are being created. Maybe this in an incorect way of doing things ? I will soon be sending a little patch using this getMinMaxContentWidth() method. No more static variable, hehehe ! So you will see what I mean. Cheers, Andreas Thank you, Patrick
Re: Q: Line-layout - separating element-list creation / line-breaking
Simon Pepping wrote: On Tue, Aug 22, 2006 at 11:35:12PM +0200, Andreas L Delmelle wrote: Hi all, I've been doing some thinking myself about the separation between element-list creation and actual line-breaking, and went wandering through the related sources. Just checking here if my initial estimates are correct. Which problem are you trying to solve? Paragraph layout where the line width changes in the paragraph? I don't know exactly what Adreas has in mind be we actually need this for the auto-table layout. Regards, Patrick
Re: Q: Line-layout - separating element-list creation / line-breaking
Andreas L Delmelle wrote: On Aug 23, 2006, at 21:16, Patrick Paul wrote: Simon Pepping wrote: On Tue, Aug 22, 2006 at 11:35:12PM +0200, Andreas L Delmelle wrote: I've been doing some thinking myself about the separation between element-list creation and actual line-breaking, and went wandering through the related sources. Just checking here if my initial estimates are correct. Which problem are you trying to solve? Paragraph layout where the line width changes in the paragraph? I don't know exactly what Adreas has in mind be we actually need this for the auto-table layout. Simon's correct. I'll clarify a bit more. From what I could tell, Patrick's patch has added code at the right places, it only seems a bit awkward to me to import stuff related to table-layout into the LineLayoutManager (even if it is nothing more than a TableHelper). I have since improved the patch to use a getMinMaxContentWidths() method that passes the values up the LMs. I will submit it soon. So the only thing remaning in the way for now is the fact that the element lists are created twice (since the line-breaking can be disabled using a switch). (Note: this part was not wrong per se in the patch. It just seems there currently is no other way, precisely because list-creation and breaking are performed in the same method. The only place where it can be entered is somewhere between those two statements -- collectInlineKnuthElements() and createLineBreaks().) A more correct approach --a matter of taste?-- would be for the TableContentLM to 'collect' the accumulated list of its descendant LMs, perform the min/max-width calculation, update the LayoutContext, and send it back down to the LineBreaker. When you say 'collect' I suppose you mean that the TableContentLM whould have to keep all the LinkedLists of elements for the entire table. I haven't looked at this closely, but wouldn't that also imply some kind of mechanism on the TableCellLM and BlockLMs when going back down to the LineBreaker to perform the line-breaking? If I understand all this correctly, it would imply holding the element lists for an entire table. Wouldn't that be expensive in terms of memory? Maybe someone sees another approach that I'm overlooking? The breaking algorithm needs to be given a LayoutContext with a certain available amount of ipd. Since the base element list does not depend on this amount --apart from the start- or end-of-paragraph elements-- this means it should be feasible to separate the former from the latter. This is how I see it too. In auto-table layout, we have to take into account the possibility that none of the column-widths are specified. Both minimum and maximum depend on the content. I think that this is not only a possibility but a common situation. I find that I often want to let the formatter determine the optimal column (and table) widths depending on the content. Strictly speaking, apart from the arbitrary default 'available ipd / # columns', you don't have a correct ipd to give to the Breaker. If you do perform the breaking, however, the element list will also contain elements that have been added by the Breaker. A way around this is to give an arbitrarly large default available ipd the first time you run through the algorithm. This reduces the extra line-breaking. Although I haven't done too much investigation on whether they influence the content-width calculation, this still means these elements are created for no reason at all. IOW: this would be a wasted trip through the breaking algorithm. Correct. This is what is happening for now. I run through the getNextKnuthElements twice: the first time to determine the minimum and maximum widths of the content, and the second to do the proper line-breaking. snip / This may be possible, but it does not seem to be in the spirit of the algorithm. The algorithm calculates the best layout up to the current linebreak. You can always interrupt the calculation and resume later, provided you keep the list of active nodes. If you want N lines, then you do not determine in advance the end element. You proceed until you have all active nodes that end line N, and then determine the best of them. But it is even better to continue to the end of the paragraph, taking the modified line width into account. That gives you the best total-fit for the whole paragraph. In that total-fit, the layout for the first N lines may be suboptimal, but then it is offset by a better result for the remaining lines. OK. This makes sense. I'm going to chew some more on this. The other consideration, but that would be for a more distant future, is to be able to have three different threads: - fo creation - base layoutengine initialization - actual breaking/layout Those could run in concert, so the layoutengine initialization does not need to wait for the endPageSequence() event, but could
Re: Fwd: svn commit: r433291 ...
Andreas L Delmelle wrote:
Begin forwarded message:
From: [EMAIL PROTECTED]
snip /
URL: http://svn.apache.org/viewvc?rev=433291view=rev
Log:
Rework of default column-creation and setting column-widths from the
first row (fixes Bugzilla 35656)
For Patrick, only this tiny bit changes:
The following part is moved from TableLM to ColumnSetup. I see in the
initial GSoC-patch that this is bypassed in case of auto-layout.
Shouldn't be too much trouble adapting the patch to take this into
account.
-// either works out table of column widths or if
proportional-column-width function
-// is used works out total factor, so that value of single
unit can be computed.
-int sumCols = 0;
-float factors = 0;
-for (Iterator i = columns.iterator(); i.hasNext();) {
-TableColumn column = (TableColumn) i.next();
-if (column != null) {
-Length width = column.getColumnWidth();
-sumCols += width.getValue(this);
-if (width instanceof TableColLength) {
-factors += ((TableColLength)
width).getTableUnits();
-}
-}
-}
-// sets TABLE_UNITS in case where one or more oldColumns is
defined using
-// proportional-column-width
-if (sumCols getContentAreaIPD()) {
-if (tableUnits == 0.0) {
-this.tableUnits = (getContentAreaIPD() - sumCols) /
factors;
-}
+/* initialize unit to determine computed values
+ * for proportional-column-width()
+ */
+if (tableUnit == 0.0) {
+this.tableUnit = columns.computeTableUnit(this);
}
Cheers,
Andreas
Andreas,
In ColumnSetup.getXOffset you use the width of the columns that are
stored in the new ArrayList named colWidths that you created. The
problem is that my algorigthm changes the widths of the columns but that
isn't reflected in colWidths, so the returned offset isn't the right one.
Maybe I missed something, or should I be updating the colWidths
ArrayList rather than widths of the columns directly ?
Thank you,
Patrick
Re: [GSoC] Auto-table layout questions
Jeremias Maerki wrote: BTW, Patrick, when I checked the ICLA status of you and Vincent I saw that you still don't have an ICLA on file with the ASF. Please sign and send (i.e. fax) one to the ASF secretary: http://www.apache.org/licenses/#clas Thanks. Jeremias Maerki Hi Jeremias, I've been offline most of the time this past week. I have faxed my ICLA a few days ago, so I'm hoping it is on file with the ASF by now. Please let me know if its not. Thank you, Patrick
Re: [GSoC] Auto-table layout questions
In turn I apologize for the delay in my response. Thank you for the answers. I am working towards the splitting, following your precious advice. I will fax my ICLA by next tuesday. I will be offline for the week-end but will continue working on my laptop. I have to start sending you my code some time soon! Thank you, Patrick Paul Jeremias Maerki wrote: Sorry for the delay. Too much going on right now. On 19.07.2006 01:37:57 Patrick Paul wrote: Just to make sure I understand things correctly, the element list construction needs to be seperated from the line breaking algorithm ONLY when using it for auto table layout ? I'd state it differently: Element list contruction needs to be separated from the line breaking algorithm in order so the auto table layout can access the element lists before the line breaking can occur. ATM, yes, it's only used for auto table layout. I am asking this because the LineLayoutManager is not used exclusively by the TableLayoutManager, right ? Yes. If this is correct, how do you recommend I do this split ? Should I create a new LineLayoutManager ? Or should I actually change the LineLayoutManger and reflect the change anywhere it is necessary in the code ? No, don't create a new LineLayoutManager. The existing one needs to be adjusted. getNextKnuthElements() in the context of the LineLayoutManager means returning a block-level element list which cannot be provided at the point where you need the inline-level element lists. So you may need to come up with a mechanism that you can call on the block-level LMs inside the table-cell so they descend down to the LineLayoutManagers and issue the construction of the inline element lists. Ideally, the LineLayoutManagers won't have to recreate the element lists when the real getNextKnuthElements() call happens but they will automatically create those element lists when they are not available, yet (i.e. in cases outside a table). HTH BTW, Patrick, when I checked the ICLA status of you and Vincent I saw that you still don't have an ICLA on file with the ASF. Please sign and send (i.e. fax) one to the ASF secretary: http://www.apache.org/licenses/#clas Thanks. Patrick Paul Jeremias Maerki wrote: Here are my notes on AutoTableLayout I collected last year in case you haven't seen them, yet. One of the more important parts will be to split up the element list construction and the line breaking in LineLayoutManager, because you can't do the line breaking as long as you don't know the available IPD. http://wiki.apache.org/xmlgraphics-fop/AutoTableLayout HTH On 18.07.2006 21:30:39 Patrick Paul wrote: Great this is exactly what I needed, just didn't know where to look (just as I received your message I had coded my own little routine). Now I need a little pointer on how best to fly over table rows without touching them. I have some idea but I would prefer to check with the experts. Thank you, Patrick Andreas L Delmelle wrote: On Jul 18, 2006, at 20:46, Patrick Paul wrote: Hi Patrick, I've been playing a little with the TableLayoutManager code. If someone would be kind enough to point me in the right direction on how to determine the full length of each element list, it would help a great deal. Depends on what you mean by 'length': if you mean content-length, have a look at layoutmgr.ElementListUtils.calcContentLength(). If you mean number of elements --but you don't, do you? ;) Cheers, Andreas Jeremias Maerki Jeremias Maerki
Re: [GSoC] Auto-table layout questions
Hi, I think I am trying to solve this the wrong way. I just realized there is a getKnuthElementsForRowIterator() method in the TableContentLM which in turn makes use of cellLM.getNextKnuthElements() ... Patrick Patrick Paul wrote: Thanks for the pointers. The intended meaning of un-touched was to say that no line-breaking or other processing takes place on the elements, just returning the element list. What is unclear to me is how I can get the element list for a specific table-cell. Here is what how I see things : 1. create a TableRowIterator for the table-body elements 2. do a prefetchAll() 3. Iterate over row = EffRow[] getNextRowGroup() 3.1 Get the element list of each table-cell ? This is where I am unsure how I should get the element lists : row.getGridUnits().getPrimary().getElements() ? 3.2 Once I have the element list of the cell I can easily get its full length. As well, is there any reading I can do to get a deeper understanding of GridUnits ? Thank you, Patrick Paul Andreas L Delmelle wrote: On Jul 18, 2006, at 21:30, Patrick Paul wrote: Now I need a little pointer on how best to fly over table rows without touching them. I have some idea but I would prefer to check with the experts. Tricky indeed... the TableRowIterator constructs the very list it is supposed to iterate over --I mean: it creates the elements from another list instead of simply returning them un-touched. prefetchAll() is unused ATM, exactly because you would touch all rows (if I catch your intended meaning of that word correctly?) OTOH, that method seems to have been added with auto-layout in mind anyway, so give it a shot, but mind the large tables... Seems like, instead of simply prefetchNext(), you could try refining it to: 1) prefetchNext() [= get the row *group*, minor yet important detail] 2) doing what you need [= calculate content-length?] 3) immediately dispose of it Another option would be to use an altered version of prefetchNext() altogether. HTH! Cheers, Andreas
Re: [GSoC] Auto-table layout questions
Hello everyone, I've been playing a little with the TableLayoutManager code. If someone would be kind enough to point me in the right direction on how to determine the full length of each element list, it would help a great deal. Thank you, Patrick Patrick Paul wrote: Hi all, I will be posting some questions under this thread about the auto-table layout I am working on. My first question, really simple but confusing to me, is about what is supposed to happen when table-layout=fixed and one of the columns has column-width=auto ? Am I supposed to find out the optimal width juste for that column ? Thank you, Patrick
Re: [GSoC] Auto-table layout questions
Great this is exactly what I needed, just didn't know where to look (just as I received your message I had coded my own little routine). Now I need a little pointer on how best to fly over table rows without touching them. I have some idea but I would prefer to check with the experts. Thank you, Patrick Andreas L Delmelle wrote: On Jul 18, 2006, at 20:46, Patrick Paul wrote: Hi Patrick, I've been playing a little with the TableLayoutManager code. If someone would be kind enough to point me in the right direction on how to determine the full length of each element list, it would help a great deal. Depends on what you mean by 'length': if you mean content-length, have a look at layoutmgr.ElementListUtils.calcContentLength(). If you mean number of elements --but you don't, do you? ;) Cheers, Andreas
Re: [GSoC] Auto-table layout questions
Thank you Jeremias, I have already read your notes and I intend to split the element list construction and the line breaking right after I've implemented a working basic auto-table layout. This will allow me to have a better understanding of how things work before tackling a more delicate task. Thanks for the help, Patrick Jeremias Maerki wrote: Here are my notes on AutoTableLayout I collected last year in case you haven't seen them, yet. One of the more important parts will be to split up the element list construction and the line breaking in LineLayoutManager, because you can't do the line breaking as long as you don't know the available IPD. http://wiki.apache.org/xmlgraphics-fop/AutoTableLayout HTH On 18.07.2006 21:30:39 Patrick Paul wrote: Great this is exactly what I needed, just didn't know where to look (just as I received your message I had coded my own little routine). Now I need a little pointer on how best to fly over table rows without touching them. I have some idea but I would prefer to check with the experts. Thank you, Patrick Andreas L Delmelle wrote: On Jul 18, 2006, at 20:46, Patrick Paul wrote: Hi Patrick, I've been playing a little with the TableLayoutManager code. If someone would be kind enough to point me in the right direction on how to determine the full length of each element list, it would help a great deal. Depends on what you mean by 'length': if you mean content-length, have a look at layoutmgr.ElementListUtils.calcContentLength(). If you mean number of elements --but you don't, do you? ;) Cheers, Andreas Jeremias Maerki
Re: [GSoC] Auto-table layout questions
Just to make sure I understand things correctly, the element list construction needs to be seperated from the line breaking algorithm ONLY when using it for auto table layout ? I am asking this because the LineLayoutManager is not used exclusively by the TableLayoutManager, right ? If this is correct, how do you recommend I do this split ? Should I create a new LineLayoutManager ? Or should I actually change the LineLayoutManger and reflect the change anywhere it is necessary in the code ? Patrick Paul Jeremias Maerki wrote: Here are my notes on AutoTableLayout I collected last year in case you haven't seen them, yet. One of the more important parts will be to split up the element list construction and the line breaking in LineLayoutManager, because you can't do the line breaking as long as you don't know the available IPD. http://wiki.apache.org/xmlgraphics-fop/AutoTableLayout HTH On 18.07.2006 21:30:39 Patrick Paul wrote: Great this is exactly what I needed, just didn't know where to look (just as I received your message I had coded my own little routine). Now I need a little pointer on how best to fly over table rows without touching them. I have some idea but I would prefer to check with the experts. Thank you, Patrick Andreas L Delmelle wrote: On Jul 18, 2006, at 20:46, Patrick Paul wrote: Hi Patrick, I've been playing a little with the TableLayoutManager code. If someone would be kind enough to point me in the right direction on how to determine the full length of each element list, it would help a great deal. Depends on what you mean by 'length': if you mean content-length, have a look at layoutmgr.ElementListUtils.calcContentLength(). If you mean number of elements --but you don't, do you? ;) Cheers, Andreas Jeremias Maerki
Re: [GSoC] Auto-table layout questions
the user doesn't specify the column-width property in which case the value is not auto but proportional-column-width(1) (see FOPropertyMapping). If that's correct and usable remains to be seen. On 13.07.2006 18:20:46 Patrick Paul wrote: Thank you for the advice. I will sum this up on the wiki page. So if I understand correctly we have to support certain values even if they are illegal ? Patrick Jeremias Maerki wrote: Right, but strictly speaking the value auto is illegal for column-width. FOP currently defaults to proportional-column-width(1) if no value is specified. Another thing we should be careful about is the distinction between the value set for table-layout and the effective algorithm to be used. If you specify table-layout=fixed but without an ipd, the rules for automatic table layout are activated. On 12.07.2006 22:55:44 Andreas L Delmelle wrote: On Jul 12, 2006, at 22:11, Patrick Paul wrote: Hi Patrick, My first question, really simple but confusing to me, is about what is supposed to happen when table-layout=fixed and one of the columns has column-width=auto ? Am I supposed to find out the optimal width juste for that column ? Yes, but with one big difference compared to table-layout=auto. IIRC, CSS mentions this case explicitly: when table-layout=fixed and column-width=auto then the column-widths are ultimately the widths necessary for the cells in the first row. No need to look at the whole table, in any case... Cheers, Andreas Jeremias Maerki Jeremias Maerki
Re: [GSoC] Auto-table layout questions
Thank you for the advice. I will sum this up on the wiki page. So if I understand correctly we have to support certain values even if they are illegal ? Patrick Jeremias Maerki wrote: Right, but strictly speaking the value auto is illegal for column-width. FOP currently defaults to proportional-column-width(1) if no value is specified. Another thing we should be careful about is the distinction between the value set for table-layout and the effective algorithm to be used. If you specify table-layout=fixed but without an ipd, the rules for automatic table layout are activated. On 12.07.2006 22:55:44 Andreas L Delmelle wrote: On Jul 12, 2006, at 22:11, Patrick Paul wrote: Hi Patrick, My first question, really simple but confusing to me, is about what is supposed to happen when table-layout=fixed and one of the columns has column-width=auto ? Am I supposed to find out the optimal width juste for that column ? Yes, but with one big difference compared to table-layout=auto. IIRC, CSS mentions this case explicitly: when table-layout=fixed and column-width=auto then the column-widths are ultimately the widths necessary for the cells in the first row. No need to look at the whole table, in any case... Cheers, Andreas Jeremias Maerki
[GSoC] Auto-table layout questions
Hi all, I will be posting some questions under this thread about the auto-table layout I am working on. My first question, really simple but confusing to me, is about what is supposed to happen when table-layout=fixed and one of the columns has column-width=auto ? Am I supposed to find out the optimal width juste for that column ? Thank you, Patrick
Re: Google Summer of Code
Hello everyone, Great news for me today, I got accepted for the Google Summer of Code to work on the auto table layout. Thank you very much Jeremias for taking the time to apply as a mentor and rank our projects. Patrick Jeremias Maerki wrote: Got it and rated it. All green! :-) On 07.05.2006 22:24:26 Vincent Hennebert wrote: Ok, this should have worked this time. Don't know what happened. Vincent Jeremias Maerki a écrit : Vincent, I'm afraid I don't see your application, either. You could simply try again or contact the GSoC support. On 07.05.2006 19:12:26 Vincent Hennebert wrote: Hi Jeremias, Normally my application should have been sent. However I don't see it on my home page so I wonder if it has to be reviewed first or if the submit has failed. The way the webapp works isn't clear to me yet. Do you see my application? Jeremias Maerki Jeremias Maerki
Re: Google Summer of Code
This is great news :-) I hope that our score(s) will stay high. Do you have your say in the score that the projects get ? Have a nice week-end, Patrick Jeremias Maerki wrote: Hi Patrick, green lights everywhere. I've already ranked it and applied for the mentor position. It turns out that the Wiki in the ASF this time only was about collecting ideas for projects (unlike last year). The real project proposals are those on the Google site. At this moment, only 7 entries (including yours) have requests for the mentor position und therefore have a score of =4. Now we only need Vincent who should be back on Sunday. If he enters his proposal then, everything should be fine. Vincent, ping me when you entered it so I can go right to the ranking part. On 05.05.2006 18:27:50 Patrick Paul wrote: Hi Jeremias, Any news from GSoC ? Were you able to see my application and rank it ? How are things going within the ASF ? Patrick
Re: Google Summer of Code
Hi Jeremias, I have submitted an application. Indeed all this is unclear, I never realized mentors also had to signup. But I'm sure that with your reputation there won't be any problems ;-) In my application I mainly copied the content of the Wiki page. Should you have any comments or suggestions to improve my proposal please don't hesitate. I'm very excited about participating in the GSoC. I hope Apache Fop is considered an mportant enough project within the ASF because it seems that many other ASF projects are making proposals. Thank you, Patrick Jeremias Maerki wrote: It looks like you two need to sign up for the GSoC directly on the website and enter your application there based on the info on the ASF Wiki. This needs to be completed until May 8. After that the applications will be rated by the mentors. To me this was all a bit confusing despite the extensive FAQs. Realized only today that I have to sign up, too, as a mentor. http://code.google.com/ On 28.04.2006 17:24:43 Patrick Paul wrote: Same here, I've added an entry for auto table layout, right after Vincents. Patrick Vincent Hennebert wrote: Ok, I've added an entry for floats implementation. I'll be off-line from tomorrow until the 6th of may. Just hoping no particular problem will occur during my absence. Anyway, if I don't answer mails that's just normal. Vincent Jeremias Maerki a écrit : Yes, please add entries for the two projects. That Wiki page is the first station. I'm not sure, yet, who exactly will transfer the proposals to Google (can't remember from last year, either), but the first step is to identify the projects inside the ASF. I'll need to read through the whole mentoring info and stuff during the weekend. You can list me as a mentor on both projects. If I can get help from another FOP committer mentoring, all the better. On 27.04.2006 16:22:44 Patrick Paul wrote: Jeremias, Do you think we should have our two projects posted on the Apache Wiki ? http://wiki.apache.org/general/SummerOfCode2006 Is it better to go through that page, or will our proposals be forwarded directly to you anyway ? Thanks, Patrick Jeremias Maerki
Re: Google Summer of Code
Same here, I've added an entry for auto table layout, right after Vincents. Patrick Vincent Hennebert wrote: Ok, I've added an entry for floats implementation. I'll be off-line from tomorrow until the 6th of may. Just hoping no particular problem will occur during my absence. Anyway, if I don't answer mails that's just normal. Vincent Jeremias Maerki a écrit : Yes, please add entries for the two projects. That Wiki page is the first station. I'm not sure, yet, who exactly will transfer the proposals to Google (can't remember from last year, either), but the first step is to identify the projects inside the ASF. I'll need to read through the whole mentoring info and stuff during the weekend. You can list me as a mentor on both projects. If I can get help from another FOP committer mentoring, all the better. On 27.04.2006 16:22:44 Patrick Paul wrote: Jeremias, Do you think we should have our two projects posted on the Apache Wiki ? http://wiki.apache.org/general/SummerOfCode2006 Is it better to go through that page, or will our proposals be forwarded directly to you anyway ? Thanks, Patrick
Re: Google Summer of Code
Jeremias, Do you think we should have our two projects posted on the Apache Wiki ? http://wiki.apache.org/general/SummerOfCode2006 Is it better to go through that page, or will our proposals be forwarded directly to you anyway ? Thanks, Patrick Jeremias Maerki wrote: I don't see why you couldn't also apply for a slot. Having floats would be cool (but not simple). I'm not sure about your work on FOrayFont. I think the projects have to be tied to one of the organizations listed by Google. Only the client part in FOP would be part of that. So floats would be the better option I guess. I'm sure I can count on other FOP committers to help me with the mentoring job if we take on two projects. BTW, both of you should make sure you're eligible for participating in the SoC. See the Students FAQ on the Google SoC site. Someone who applied last year wasn't a student. Jeremias Maerki
Re: Google Summer of Code
Thank you Jeremias for your amendements. Patrick Jeremias Maerki wrote: Thanks, Vincent and Patrick, for writing down your proposals. Patrick's is pretty clear. I've only amended it a little. I hope it won't be a problem that the task cannot be well estimated, yet. Vincent, a comment on yours: For before-floats, you refer to best-fit and first-fit approaches. I'm not sure if it's really relevant here. If I'm not mistaken before-floats are pretty similar to footnotes which means you can probably take a lot from there. I think that first-fit only really helps when you get to side-floats. I think that user-configuration for best/first-fit doesn't help much. I rather think that FOP will have to find out itself whether it has to abandon best-fit so it can handle more complex features, i.e. switching to first-fit if it finds one of the following conditions: - side-float in the flow - page-masters with different available IPD in the flow - tables with auto table layout (when individual column widths are requested for each page) Note that I'm not completely sure about the above. Maybe Luca Furini has some helpful insight here. On 24.04.2006 01:07:38 Vincent Hennebert wrote: Hi, I'm thinking about setting up a page on the FOP-wiki where I would put up the goals for my proposal. That way I could give the link when submitting my application. Nice idea, indeed. I've taken the liberty of implementing it and created a new Wiki page for the SoC, linked from the DeveloperPages [1]. The idea is to have a main page listing the various proposals, with a link to each proposal's dedicated page. You'll just have to add yours. I've put a first draft regarding float implementation. Any comment is welcome, especially regarding scheduling (I've no idea of the time each task may need - never done project estimations!), and typos. Thanks. Vincent [1] http://wiki.apache.org/xmlgraphics-fop/GoogleSummerOfCode2006 Jeremias Maerki
Re: Google Summer of Code
That's great thank you. I added my own page. It's only a start for now. I took some presentation ideas from you, I hope you don't mind too much. I won't mind if you do the same in the future. Cheers, Patrick Vincent Hennebert wrote: Hi, I'm thinking about setting up a page on the FOP-wiki where I would put up the goals for my proposal. That way I could give the link when submitting my application. Nice idea, indeed. I've taken the liberty of implementing it and created a new Wiki page for the SoC, linked from the DeveloperPages [1]. The idea is to have a main page listing the various proposals, with a link to each proposal's dedicated page. You'll just have to add yours. I've put a first draft regarding float implementation. Any comment is welcome, especially regarding scheduling (I've no idea of the time each task may need - never done project estimations!), and typos. Thanks. Vincent [1] http://wiki.apache.org/xmlgraphics-fop/GoogleSummerOfCode2006
Re: Google Summer of Code
Hi Jeremias, I am happy to know you have a good impression of me. I do have good Java skills, from personal experience as well as from 4 university courses that involved Java. Implementing the auto table layout sounds like the kind of contribution I would really enjoy bringing to the FOP project. As I do not know the specifics yet, would you consider this to be a project of its own, or would other things have to be added to the proposal ? Google will start taking proposals on may 1st so there is still time to prepare, but I think it is best to have a well thought-out application with a good timetable and realistic goals that fit into the bigger picture of FOP. I look forward to work with you again. Patrick Jeremias Maerki wrote: Hi Patrick, yes, I've seen that something's going on in that corner. After my experience last year, I was a bit hesitant to take another stab, but since we've already worked together, I'd be fine mentoring a little project. There are a lot of things that could be approached: http://wiki.apache.org/xmlgraphics-fop/FOPProjectTasks The thing that would make the most people happy would be implementing auto table layout. That's something that is not on any of my clients' wishlists so it goes on my private task list on which I have other higher priority items. :-o You'd be the hero implementing that! I'm sure there are other things you could do. You've got good Java skills, haven't you? On 18.04.2006 20:53:30 Patrick Paul wrote: Hello everyone, As you may know Google is doing their Summer of Code program again this summer. http://code.google.com/soc/ I would be interested in applying to do some work on FOP this summer. Would you have suggestions about specific developments that would greatly help improve FOP ? I'm looking forward to hear from you all. FOP is so great. Thank you, Patrick Jeremias Maerki
Re: Google Summer of Code
I did make sure I am eligible for the Google SoC, and I will gladly give you all the details you want or need if you request them. As far as I know there are no restrictions to the number of slots a project can get, although this year it seams much more people are interested in the Google Summer of Code. Also, FOP is a project of the ASF which is just one of the many mentoring organizations... Anyway, I sure hope we can both get accepted to work on FOP this summer. Patrick Jeremias Maerki wrote: I don't see why you couldn't also apply for a slot. Having floats would be cool (but not simple). I'm not sure about your work on FOrayFont. I think the projects have to be tied to one of the organizations listed by Google. Only the client part in FOP would be part of that. So floats would be the better option I guess. I'm sure I can count on other FOP committers to help me with the mentoring job if we take on two projects. BTW, both of you should make sure you're eligible for participating in the SoC. See the Students FAQ on the Google SoC site. Someone who applied last year wasn't a student. On 19.04.2006 21:17:10 Vincent Hennebert wrote: Patrick, you were faster than me ;-) I would also be interesting in applying to the Summer of Code. It would at last give me the opportunity to work full-time on Fop. Is it conceivable that I also apply, along with Patrick? Although I'm a bit doubtful that my work on FOrayFont could be eligible as a project for Fop, we may investigate. Otherwise, one thing I'm dreaming of for long but that I'll never have time to do is float implementation, both before-floats and side-floats. I think there is a number of Docbook users using Fop for PDF output who would benefit from that. What's your opinion? Vincent Patrick Paul a écrit : Hello everyone, As you may know Google is doing their Summer of Code program again this summer. http://code.google.com/soc/ I would be interested in applying to do some work on FOP this summer. Would you have suggestions about specific developments that would greatly help improve FOP ? I'm looking forward to hear from you all. FOP is so great. Thank you, Patrick Jeremias Maerki
Re: Google Summer of Code
Jeremias, I think this is most reasonable. In any case I whish to contribute as mush as possible. I'm thinking about setting up a page on the FOP-wiki where I would put up the goals for my proposal. That way I could give the link when submitting my application. Also, I will be in Europe in June, so I'm seriously considering coming to Dublin for the ApacheCon Europe. Patrick P.S. When I see all the people showing interest in the SoC, I'm starting to think I shouldn't get my hopes to high. Jeremias Maerki wrote: We can set it up so the basic auto table layout is the main goal and then we add some optional additional goals. That should help making sure we don't set the bar unrealistically high if we can't do a good estimate. I'm glad to hear you want to contribute beyond the SoC boundaries. It's good to get new blood into the project. On 19.04.2006 18:38:35 Patrick Paul wrote: Jeremias Maerki wrote: Patrick, I have the suspicion that the auto table layout won't fill you up. With the new design, basic support for auto table layout shouldn't be a very big deal. There are some details, however, that could make this a much bigger fish: I did suspect it would not be enough. Determining ideal column widths based on the inline elment lists for the whole table should be relatively easy. You would probably have that within two or three weeks after a, say, four-week get-to-know-FOP-better phase. It gets more difficult if the column widths are to be redetermined for each page (if that's requested). FOP cannot currently do that because it determines page breaks on a number of pages at the same time (total fit algorithm instead of first fit (Knuth terminology)). This would cause extensive changes to the whole layout engine but enable other features that are currently not possible, for example changing available IPD between pages. Sounds interesting, and it would be a good challenge for me to tackle. The four-week get-to-know-FOP-better period you suggest sounds very reasonable to me. Another thing that just crossed my mind would be a total refactoring of the images package. I'm itching to do that for a long time now but probably won't have time for it in the near furture. I've written down some thoughts about that [1] and can elaborate if necessary. [1] http://wiki.apache.org/xmlgraphics-fop/ImageSupport Sounds good too. I'll have to trust you about what kind of workload this would all add up too. I'd like to be as realistic as possible since it is important to meet the initial objectives of the proposal. In any case I am motivated to actively contribute beyond the Google SoC. Patrick Jeremias Maerki
Google Summer of Code
Hello everyone, As you may know Google is doing their Summer of Code program again this summer. http://code.google.com/soc/ I would be interested in applying to do some work on FOP this summer. Would you have suggestions about specific developments that would greatly help improve FOP ? I'm looking forward to hear from you all. FOP is so great. Thank you, Patrick
Website refactoring
Hi, I will be fixing the BROKEN: No pipeline matched request: warnings in the next few days for the new refactored website. If anyone has other requests or ideas for the new website I would be glad to hear about them. Have a nice day everyone. Patrick Paul
Re: FOP website, release preparations: refactoring necessary
I apologize for not responding sooner, but I've been very busy lately. Anyways, I've finally found some time to get working on the website. I think I got everything right, now I just need to work on some broken links. Also, I am wondering if the svn diff will show everything (I moved some files around, for example the ones listed below are now in a directory called 0.20.5). I hope this is not a big issue. Cheers, Patrick Paul Jeremias Maerki wrote: Ok, so let's try to come up with a list. I see: The whole Using FOP section - compiling.xml - configuration.xml - running.xml - embedding.xml - servlets.xml - anttask.xml then most of Features: - output.xml - pdfencryption.xml - graphics.xml - fonts.xml - hyphenation.xml - extensions.xml The only item left out is this last section was compliance.xml which contains information for both versions. I'm not sure what to do with it. On 29.08.2005 00:10:31 Patrick Paul wrote: Now I have to determine what goes in the 2 newly created tabs. ;-) Jeremias Maerki
Re: Let's write the release plan for the first preview release
Jeremias Maerki wrote: Like others I'm hesitant to call it 1.0 just yet. 0.9 sends the right signal IMO. We're not quite where we want to be but we are soon and people can start looking at the new package. (..) Jeremias Maerki I agree, we have to be carefull to send the right message. Patrick Paul
Re: FOP website, release preparations: refactoring necessary
Just an update to let you know I should have something ready to show you this week-end. Patrick Paul Jeremias Maerki wrote: Ok, so let's try to come up with a list. I see: The whole Using FOP section - compiling.xml - configuration.xml - running.xml - embedding.xml - servlets.xml - anttask.xml then most of Features: - output.xml - pdfencryption.xml - graphics.xml - fonts.xml - hyphenation.xml - extensions.xml The only item left out is this last section was compliance.xml which contains information for both versions. I'm not sure what to do with it. On 29.08.2005 00:10:31 Patrick Paul wrote: Now I have to determine what goes in the 2 newly created tabs. ;-) Jeremias Maerki
Re: FOP website, release preparations: refactoring necessary
I was talking about their website (with the two tabs for the different versions) , not their product. Patrick Jeremias Maerki wrote: Uh, oh. Sorry, but I don't think we'll do that. We don't even have the infrastructure for a Lenya installation and I wouldn't want to rewrite our whole website just now. That would distract me too much at this stage of development. Even the Lenya project uses Forrest for their website. :-) On 27.08.2005 04:31:55 Patrick Paul wrote: Ok, so from what I understand you want to do, I think that what the Lenya project did looks good. http://lenya.apache.org/ What do you think ? Patrick Paul Jeremias Maerki wrote: While we're at it: In preparation for the first release we need to start thinking about a refactoring of our website. Since FOP 0.20.5 will probably stay the preferred productive version for some time and FOP Trunk is substantially different, I'd like to propose doing a version split like Forrest [1] have done. That would involve factoring out the version-dependent docs into a separate tab (or something like that), so we can have info for both versions side-by-side for the time being. I think stuff like embedding info would become too complicated and unreadable if we tried to put everything in the same place. If anyone would like to take the lead here, I'd be grateful. Otherwise, I will squeeze it in somewhere. [1] http://forrest.apache.org Jeremias Maerki Jeremias Maerki
Re: FOP website, release preparations: refactoring necessary
Perfect, I will be working towards something like that. Patrick Paul Jeremias Maerki wrote: Sorry, I got the wrong impression. Since it's a CMS I thought you suggested we use that. But you're right. The tab structure like Lenya has it is exactly what we need. I think we'll end up with the following tabs: - Home - 0.20.5 - 1.0dev - Development (It's probably best to collapse Development and Design into one tab. Too many tabs are not ideal. If anyone has better ideas, please bring'em up. On 27.08.2005 15:57:02 Patrick Paul wrote: I was talking about their website (with the two tabs for the different versions) , not their product. Patrick Jeremias Maerki wrote: Uh, oh. Sorry, but I don't think we'll do that. We don't even have the infrastructure for a Lenya installation and I wouldn't want to rewrite our whole website just now. That would distract me too much at this stage of development. Even the Lenya project uses Forrest for their website. :-) On 27.08.2005 04:31:55 Patrick Paul wrote: Ok, so from what I understand you want to do, I think that what the Lenya project did looks good. http://lenya.apache.org/ What do you think ? Patrick Paul Jeremias Maerki wrote: While we're at it: In preparation for the first release we need to start thinking about a refactoring of our website. Since FOP 0.20.5 will probably stay the preferred productive version for some time and FOP Trunk is substantially different, I'd like to propose doing a version split like Forrest [1] have done. That would involve factoring out the version-dependent docs into a separate tab (or something like that), so we can have info for both versions side-by-side for the time being. I think stuff like embedding info would become too complicated and unreadable if we tried to put everything in the same place. If anyone would like to take the lead here, I'd be grateful. Otherwise, I will squeeze it in somewhere. [1] http://forrest.apache.org Jeremias Maerki Jeremias Maerki Jeremias Maerki
Re: FOP website, release preparations: refactoring necessary
Ok, so from what I understand you want to do, I think that what the Lenya project did looks good. http://lenya.apache.org/ What do you think ? Patrick Paul Jeremias Maerki wrote: While we're at it: In preparation for the first release we need to start thinking about a refactoring of our website. Since FOP 0.20.5 will probably stay the preferred productive version for some time and FOP Trunk is substantially different, I'd like to propose doing a version split like Forrest [1] have done. That would involve factoring out the version-dependent docs into a separate tab (or something like that), so we can have info for both versions side-by-side for the time being. I think stuff like embedding info would become too complicated and unreadable if we tried to put everything in the same place. If anyone would like to take the lead here, I'd be grateful. Otherwise, I will squeeze it in somewhere. [1] http://forrest.apache.org Jeremias Maerki
Re: FOP website, release preparations: refactoring necessary
I have figured out how the documentation files work and how to edit them. I still have to figure out how to get the site to build on my local machine and then I will be in business. What way you suggest I send the changes to you ? Thanks, Patrick Paul Jeremias Maerki wrote: Very cool! Thanks a lot! If you need any help, just yell. On 23.08.2005 14:37:38 Patrick Paul wrote: I would like to take care of that. I should have some free time in the next few weeks, so I will start doing a little bit everyday starting Wednesday. Patrick Jeremias Maerki wrote: While we're at it: In preparation for the first release we need to start thinking about a refactoring of our website. Since FOP 0.20.5 will probably stay the preferred productive version for some time and FOP Trunk is substantially different, I'd like to propose doing a version split like Forrest [1] have done. That would involve factoring out the version-dependent docs into a separate tab (or something like that), so we can have info for both versions side-by-side for the time being. I think stuff like embedding info would become too complicated and unreadable if we tried to put everything in the same place. If anyone would like to take the lead here, I'd be grateful. Otherwise, I will squeeze it in somewhere. [1] http://forrest.apache.org Jeremias Maerki Jeremias Maerki
Re: FOP website, release preparations: refactoring necessary
I would like to take care of that. I should have some free time in the next few weeks, so I will start doing a little bit everyday starting Wednesday. Patrick Jeremias Maerki wrote: While we're at it: In preparation for the first release we need to start thinking about a refactoring of our website. Since FOP 0.20.5 will probably stay the preferred productive version for some time and FOP Trunk is substantially different, I'd like to propose doing a version split like Forrest [1] have done. That would involve factoring out the version-dependent docs into a separate tab (or something like that), so we can have info for both versions side-by-side for the time being. I think stuff like embedding info would become too complicated and unreadable if we tried to put everything in the same place. If anyone would like to take the lead here, I'd be grateful. Otherwise, I will squeeze it in somewhere. [1] http://forrest.apache.org Jeremias Maerki
Re: Code cleanup questions
J.Pietschmann wrote: Hi devs, in yet another attempt at getting back into FOP development I got distracted again by question regarding cleanup and testcases. (...) - The README in /docs is outdated - Much of the content in /docs seems to be obsolete too. (...) I intend to take car of the docs. Regards J.Pietschmann Regards, Patrick Paul
Extend compliance document
Hi, My name is Patrick Paul and I just joined the fop-dev mailing list. As a first contribution to the project, I would like to extend the compliance document to show 1.0dev capabilities and allow comparison between 0.20.5 and 1.0dev. Afterwards I hope to extend the documentation in general. For now, I have the following question: where do I get the information about the capabilities of FOP-1.0dev ? Patrick Paul
