Re: [GSoC] Auto-table layout questions
On 17.08.2006 04:00:30 Patrick Paul wrote: Jeremias Maerki wrote: Patrick, your ICLA hasn't shown up, yet. The last batch of ICLAs was committed 2006-07-31 so if you sent it after that date, it may show up in the next batch which I hope will be soon. It was sent after august first, around the 2nd or 3rd of august. I hope it will show up reel soon. Unfortunately, it hasn't. Jim Jagielski has recorded another batch on Tuesday where your name was still missing. Sounds to me like something went bad with the fax. Shrug. :-( What you can do if you have a scanner, is: Therefore, we are now accepting readable scanned images, sent via Email, but ONLY under the following conditions: 1. The Email MUST be sent to [EMAIL PROTECTED] AND [EMAIL PROTECTED] 2. Once received and verified as readable, the iclas.txt file will be updated with the information. Updating of the iclas.txt file will follow the same procedure as currently implemented: any officer can add an entry but it does not become official until acked and moved to the secretary's section of the file. So, if you put me ([EMAIL PROTECTED]) in the To: list of that mail you're already ok on the ICLA side and we don't have any further delays. I can also start up my fax software and you can send me that fax again and I'll handle the rest. If you want to do that, just contact me over IM. Have you made any progress on your side? Everything working out? I'm getting there... I've implemented a basic auto table layout but I still need to get the whole split done for the InlineElement.getNextKnuthElements. Currently I the element lists are created twice in order to determine the optimal width of each column. I am currently preparing some content to update the wiki page and explain everything... I have to learn to communicate *much* more. Hmm, yeah, that wouldn't hurt. Remember that the GSoC ends next Monday. I'll take a look at your initial draft patch ASAP. Patrick Paul On 07.08.2006 02:58:57 Patrick Paul wrote: 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 Jeremias Maerki Jeremias Maerki
Re: [GSoC] Auto-table layout questions
Patrick, your ICLA hasn't shown up, yet. The last batch of ICLAs was committed 2006-07-31 so if you sent it after that date, it may show up in the next batch which I hope will be soon. Have you made any progress on your side? Everything working out? On 07.08.2006 02:58:57 Patrick Paul wrote: 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 Jeremias Maerki
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
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
Hi Patrick The table doesn't disappear on my end whatever I do to the table-column elements, even if I remove them. Not sure what you're seeing there. On 18.07.2006 06:22:53 Patrick Paul wrote: Hello everyone, I've been doing a little test using the following xsl-fo. Everything works fine except when I suppress all the column-width=... in the first table then FOP doesn't give any warnings and the second table simply disappears. I'm not sure why this is happening. snip/ Jeremias Maerki
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
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
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
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
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
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
Hello everyone, I've been doing a little test using the following xsl-fo. Everything works fine except when I suppress all the column-width=... in the first table then FOP doesn't give any warnings and the second table simply disappears. I'm not sure why this is happening. Patrick ?xml version=1.0 encoding=utf-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; !-- defines the layout master -- fo:layout-master-set fo:simple-page-master master-name=first page-height=29.7cm page-width=21cm margin-top=1cm margin-bottom=2cm margin-left=2.5cm margin-right=2.5cm fo:region-body margin-top=3cm/ fo:region-before extent=3cm/ fo:region-after extent=1.5cm/ /fo:simple-page-master /fo:layout-master-set !-- starts actual layout -- fo:page-sequence master-reference=first fo:flow flow-name=xsl-region-body !-- this defines a title level 1-- fo:block font-size=18pt font-family=sans-serif line-height=24pt space-after.optimum=15pt background-color=blue color=white text-align=center padding-top=3pt Auto table layout test /fo:block !-- this defines a title level 2-- fo:block font-size=16pt font-family=sans-serif space-after.optimum=15pt text-align=center A simple table -- fixed layout /fo:block !-- normal text -- fo:block text-align=startThis simple table uses table-layout=fixed which works fine with Apache FOP 0.92beta. /fo:block !-- table start -- fo:table table-layout=fixed width=100% border-collapse=separate fo:table-column column-width=30mm/ fo:table-column column-width=30mm/ fo:table-column column-width=100mm/ fo:table-body fo:table-row fo:table-cell fo:blockone/fo:block/fo:table-cell fo:table-cell fo:blocktwo/fo:block/fo:table-cell fo:table-cell fo:blockthree: a little more texte is nice./fo:block/fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:blockun/fo:block/fo:table-cell fo:table-cell fo:blockdeux/fo:block/fo:table-cell fo:table-cell fo:blocktrois/fo:block/fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:blockuno/fo:block/fo:table-cell fo:table-cell fo:blockdos/fo:block/fo:table-cell fo:table-cell fo:blocktres/fo:block/fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:blockeins/fo:block/fo:table-cell fo:table-cell fo:blockzwei/fo:block/fo:table-cell fo:table-cell fo:blockdrei/fo:block/fo:table-cell /fo:table-row /fo:table-body /fo:table !-- table end -- !-- normal text -- fo:block text-align=startThis is normal text. /fo:block !-- NEW PAGE * -- !-- this defines a title level 2-- fo:block font-size=16pt font-family=sans-serif space-after.optimum=15pt text-align=center break-before=page A simple table -- auto-table layout /fo:block !-- normal text -- fo:block text-align=startThis the same simple table but using table-layout=auto which IS NOT supported by Apache FOP 0.92beta. /fo:block !-- table start -- fo:table table-layout=auto width=100% border-collapse=separate fo:table-column / fo:table-column / fo:table-column / fo:table-body fo:table-row fo:table-cell fo:blockone/fo:block/fo:table-cell fo:table-cell fo:blocktwo/fo:block/fo:table-cell fo:table-cell fo:blockthree: a little more texte is nice./fo:block/fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:blockun/fo:block/fo:table-cell fo:table-cell fo:blockdeux/fo:block/fo:table-cell fo:table-cell fo:blocktrois/fo:block/fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:blockuno/fo:block/fo:table-cell fo:table-cell fo:blockdos/fo:block/fo:table-cell fo:table-cell fo:blocktres/fo:block/fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:blockeins/fo:block/fo:table-cell fo:table-cell fo:blockzwei/fo:block/fo:table-cell fo:table-cell fo:blockdrei/fo:block/fo:table-cell /fo:table-row /fo:table-body /fo:table !-- table end -- !-- normal text -- fo:block text-align=startThe desired optimal result here is to have the third column made larger so that the text can fit without a line-break. /fo:block /fo:flow /fo:page-sequence /fo:root Jeremias Maerki wrote: Uh, no. I just wanted to point out that auto is not a valid value for column-width. What you probably meant was the case when the
Re: [GSoC] Auto-table layout questions
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
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
Re: [GSoC] Auto-table layout questions
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
