RE: Alternatives to auto table layout
> -Original Message- > From: Julian Reschke [mailto:[EMAIL PROTECTED] > Hi Julian, > James Earl wrote: > > ... > > Well, at least now I understand why! Man, this is easy, who needs auto > > table layout!!! > > Well. If it's that easy, I don't understand why FOP can't do this on > it's own rather than requiring special workarounds... > Well, you're welcome to have a go, if you feel like it :) (--and if you do, please patch it to the development version... I'm still not completely sure about how exactly to implement it over there) Big difference is: in XSLT you're just dealing with XML nodes, so if you know XML you're set. On top of that XSLT is a widely known standard, whereas the FOP API is only known to those who take the time to go strolling through the code and browse the dev pages... If you have an XSLT question, post it to Mulberry and suddenly 10 kind people will answer your hail. If you have a question about the FOP API, you can browse fop-dev pages or post it to fop-dev, but chances are that in the end you're still going to have to gather the necessary info to be able to answer your own question. (--Certainly no negative feelings about this, as IMHO the knowledge you gather tends to be more profound if you obtain it through self-study and a few helpful hints from co-committers, rather than having someone spell it out for you from A to Z) I guess what I mean is: there's books about XML, XSLT and Java, but you won't find a book about the FOP API. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Alternatives to auto table layout
On Wed, 2004-05-26 at 11:50, Andreas L. Delmelle wrote: > > -Original Message- > > From: James Earl [mailto:[EMAIL PROTECTED] > > > > Hi James, > > > I'm not sure if I'm doing this right... but the following gave > > acceptable results: > > > > > Total: 53 > > > > So far, you're on the right track, but... > > > Calculations: > > > > 1. (20 / 53) * 33 = 12.5 (e.g. proportional-column-width(12.5)) > > 2. (10 / 53) * 43 = 8.1 > > 3. (5 / 53) * 48 = 4.5 > > 4. (1 / 53) * 52 = 0.9 > > 5. (11 / 53) * 42 = 8.7 > > 6. (6 / 53) * 47 = 5.3 > > > > Errm... Actually, what I meant was (for a table with total width of, say > 160mm) > > 1. (20 / 53) * 160mm = 60.38mm (= proportional-column-width(20)) > 2. (10 / 53) * 160mm = 30.19mm (= proportional-column-width(10)) > etc. > > The ratio between the two first columns is always 2 to 1 (between the first > and third it will be 4 to 1, second to third again 2 to 1...) and this ratio > will remain the same, regardless of the width the parent table has. The > ratio between the width of a given column and the total width of the table > is always > > ( proportion of the column ) to ( sum of all proportions ) > > > The idea is to determine the proportions based on the max number of > characters in the content of the column. Kind of a forced idea, though... > It's not always guaranteed that, because content in column A is maximum 20 > characters while column B has a maximum of 15, the respective columns will > have a 4 to 3 ratio (--if you're using a proportional font, for example, in > column A the maximum of 20 could refer to 20 letters 'i', while the other > column has 15 letters 'M' that will take up more space) > > Anyway, look at it this way: at XSLT stage, *you* can anticipate things like > these, without FOP ever needing to know anything about the actual content of > the table-cells. > > > Hope this makes it even clearer :) Yes, this is definitely clearer. With a table width of a 100% it's just a little easier. This is working very well for me now. Thanks for all your help! James > > Cheers, > > Andreas > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Alternatives to auto table layout
> -Original Message- > From: James Earl [mailto:[EMAIL PROTECTED] > Hi James, > I'm not sure if I'm doing this right... but the following gave > acceptable results: > > Total: 53 > So far, you're on the right track, but... > Calculations: > > 1. (20 / 53) * 33 = 12.5 (e.g. proportional-column-width(12.5)) > 2. (10 / 53) * 43 = 8.1 > 3. (5 / 53) * 48 = 4.5 > 4. (1 / 53) * 52 = 0.9 > 5. (11 / 53) * 42 = 8.7 > 6. (6 / 53) * 47 = 5.3 > Errm... Actually, what I meant was (for a table with total width of, say 160mm) 1. (20 / 53) * 160mm = 60.38mm (= proportional-column-width(20)) 2. (10 / 53) * 160mm = 30.19mm (= proportional-column-width(10)) etc. The ratio between the two first columns is always 2 to 1 (between the first and third it will be 4 to 1, second to third again 2 to 1...) and this ratio will remain the same, regardless of the width the parent table has. The ratio between the width of a given column and the total width of the table is always ( proportion of the column ) to ( sum of all proportions ) The idea is to determine the proportions based on the max number of characters in the content of the column. Kind of a forced idea, though... It's not always guaranteed that, because content in column A is maximum 20 characters while column B has a maximum of 15, the respective columns will have a 4 to 3 ratio (--if you're using a proportional font, for example, in column A the maximum of 20 could refer to 20 letters 'i', while the other column has 15 letters 'M' that will take up more space) Anyway, look at it this way: at XSLT stage, *you* can anticipate things like these, without FOP ever needing to know anything about the actual content of the table-cells. Hope this makes it even clearer :) Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternatives to auto table layout
On Wed, 2004-05-26 at 11:36, James Earl wrote: > On Wed, 2004-05-26 at 11:32, Julian Reschke wrote: > > James Earl wrote: > > > ... > > > Well, at least now I understand why! Man, this is easy, who needs auto > > > table layout!!! > > > > Well. If it's that easy, I don't understand why FOP can't do this on > > it's own rather than requiring special workarounds... > > > > Julian > > I was just thinking the same thing! :) > > I'm sure there's some technical explanation that's way over my head. > > James I think I may have spoken too soon. It isn't quite working as well as I would like on some of my larger result sets, with more columns. James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternatives to auto table layout
On Wed, 2004-05-26 at 11:32, Julian Reschke wrote: > James Earl wrote: > > ... > > Well, at least now I understand why! Man, this is easy, who needs auto > > table layout!!! > > Well. If it's that easy, I don't understand why FOP can't do this on > it's own rather than requiring special workarounds... > > Julian I was just thinking the same thing! :) I'm sure there's some technical explanation that's way over my head. James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternatives to auto table layout
James Earl wrote: ... Well, at least now I understand why! Man, this is easy, who needs auto table layout!!! Well. If it's that easy, I don't understand why FOP can't do this on it's own rather than requiring special workarounds... Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Alternatives to auto table layout
On Wed, 2004-05-26 at 11:12, James Earl wrote: > On Wed, 2004-05-26 at 10:08, James Earl wrote: > > On Tue, 2004-05-25 at 18:14, Andreas L. Delmelle wrote: > > > > > Say you have a max record width (sum of all respective max field widths) > > > of > > > 65, then each column gets its width according to a calculation like > > > > > > [( proportional-width / 65 ) * remaining-table-width ] > > > > I'll post any success that I have! > > I'm not sure if I'm doing this right... but the following gave > acceptable results: > > Columns (max field length): > > 1. 20 > 2. 10 > 3. 5 > 4. 1 > 5. 11 > 6. 6 > > Total: 53 > > Calculations: > > 1. (20 / 53) * 33 = 12.5 (e.g. proportional-column-width(12.5)) > 2. (10 / 53) * 43 = 8.1 > 3. (5 / 53) * 48 = 4.5 > 4. (1 / 53) * 52 = 0.9 > 5. (11 / 53) * 42 = 8.7 > 6. (6 / 53) * 47 = 5.3 > > I've just tried this once so far, but it worked great. I have two > templates set up. Once exports xsl-fo, while the other one exports > html. The PDF generated by FOP looks almost identical in terms of the > column widths. > > I just need to take into account the max length of the column heading > when it is larger than the column data. > > James Okay, I see now that a string length WILL WORK! Man do I feel stupid. :) Well, at least now I understand why! Man, this is easy, who needs auto table layout!!! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Alternatives to auto table layout
On Wed, 2004-05-26 at 10:08, James Earl wrote: > On Tue, 2004-05-25 at 18:14, Andreas L. Delmelle wrote: > > > Say you have a max record width (sum of all respective max field widths) of > > 65, then each column gets its width according to a calculation like > > > > [( proportional-width / 65 ) * remaining-table-width ] > > I'll post any success that I have! I'm not sure if I'm doing this right... but the following gave acceptable results: Columns (max field length): 1. 20 2. 10 3. 5 4. 1 5. 11 6. 6 Total: 53 Calculations: 1. (20 / 53) * 33 = 12.5 (e.g. proportional-column-width(12.5)) 2. (10 / 53) * 43 = 8.1 3. (5 / 53) * 48 = 4.5 4. (1 / 53) * 52 = 0.9 5. (11 / 53) * 42 = 8.7 6. (6 / 53) * 47 = 5.3 I've just tried this once so far, but it worked great. I have two templates set up. Once exports xsl-fo, while the other one exports html. The PDF generated by FOP looks almost identical in terms of the column widths. I just need to take into account the max length of the column heading when it is larger than the column data. James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Alternatives to auto table layout
On Tue, 2004-05-25 at 18:14, Andreas L. Delmelle wrote: > > -Original Message- > > From: James Earl [mailto:[EMAIL PROTECTED] > > > > Hi James, > > > Thanks for the example. > > > > vMax is a string length in this example though, right? Correct me if > > I'm wrong, but I don't think proportional-column-width() will work with > > a string length will it? > > > > Hmm.. Not sure what *exactly* you are referring to, but XSLT's > string-length() function returns a number, and that number is what gets fed > to the proportional-column-width() function. > > Don't know if you have read up on the definition of > proportional-column-width(), but it works more or less as follows: > > - first all other specified column-widths are resolved (explicitly set to an > absolute or a percentage value) > - the total of these is subtracted from the table-width > - then, for all remaining columns whose width is defined by p-c-w(), the > total of the numbers is made, and the remaining table-width is distributed > over these columns along the proportions that are specified > > So, if you have two columns like this: > > > > The second one will always be 5 times as wide as the first, no matter what > else... I did read up on proportional-column-width() on w3.org, but your description of it makes things more clear. Thanks! I understand your example above, where one column is always 5 times as wide as the first. The only thing that was confusing me is that (in your first example) if string-length() returned a value of say 24, because you have a column with a maximum string length of 24 characters, then that column would be 24 times the width of all the rest... wouldn't it??? > > Using string-length() is indeed a bit rudimentary, in that it can, strictly > speaking, only approach the actual text-width when a fixed-width font is > used further on. If you want to refine that, you would need to take into > account the font-metrics as well... Also, the proportions will only look > nice if you have all rows of the same height (meaning: no line-breaks inside > cells) Sure, this too can be compensated for. > > Say you have a max record width (sum of all respective max field widths) of > 65, then each column gets its width according to a calculation like > > [( proportional-width / 65 ) * remaining-table-width ] I'm very poor with math, but this makes more sense to me (the paragraphs above) - using the maximum string lengths to calculate a proportional integer. I'll have to try to apply this in my application and see if I can better understand it through doing it! > > Other than that... could it be that you're a bit misled by the subtle > difference between XSLT and XSL-FO (?) The result of string-length() is > resolved long before FOP starts digesting the actual fo:table-column, so FOP > sees nothing of the string-length() function. That's the XSLT processor's > realm... Ya, XSLT just spits out the XSL-FO, which is then processed by FOP. I don't think I have a complete understanding of proportional-column-width() yet. I'll play around with it some more using the information you'd provided to me and see what I can learn. Thanks I'll post any success that I have! > HTH! > > Greetz, > > Andreas > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Alternatives to auto table layout
> -Original Message- > From: James Earl [mailto:[EMAIL PROTECTED] > Hi James, > Thanks for the example. > > vMax is a string length in this example though, right? Correct me if > I'm wrong, but I don't think proportional-column-width() will work with > a string length will it? > Hmm.. Not sure what *exactly* you are referring to, but XSLT's string-length() function returns a number, and that number is what gets fed to the proportional-column-width() function. Don't know if you have read up on the definition of proportional-column-width(), but it works more or less as follows: - first all other specified column-widths are resolved (explicitly set to an absolute or a percentage value) - the total of these is subtracted from the table-width - then, for all remaining columns whose width is defined by p-c-w(), the total of the numbers is made, and the remaining table-width is distributed over these columns along the proportions that are specified So, if you have two columns like this: The second one will always be 5 times as wide as the first, no matter what else... Using string-length() is indeed a bit rudimentary, in that it can, strictly speaking, only approach the actual text-width when a fixed-width font is used further on. If you want to refine that, you would need to take into account the font-metrics as well... Also, the proportions will only look nice if you have all rows of the same height (meaning: no line-breaks inside cells) Sure, this too can be compensated for. Say you have a max record width (sum of all respective max field widths) of 65, then each column gets its width according to a calculation like [( proportional-width / 65 ) * remaining-table-width ] Other than that... could it be that you're a bit misled by the subtle difference between XSLT and XSL-FO (?) The result of string-length() is resolved long before FOP starts digesting the actual fo:table-column, so FOP sees nothing of the string-length() function. That's the XSLT processor's realm... HTH! Greetz, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Alternatives to auto table layout
On Tue, 2004-05-25 at 16:08, Andreas L. Delmelle wrote:
> > -Original Message-
> > From: James Earl [mailto:[EMAIL PROTECTED]
> >
>
> Hi,
>
>
> > I'm just curious to know what people have found works best for them as
> > an alternative to achieving somewhat auto table layout? I'm currently
> > trying to figure out what I should do. I've just started learning XSL
> > as a result of beginning to use FOP to try to automatically create a
> > catalogue from data stored within a MySQL database.
> >
> > The only idea I've had so far, was to use the maximum column lengths as
> > returned from PHP's mysql_fetch_field() to somehow formulate a
> > proportional-column-width() value for the column-widths.
> >
> > As for the formula... I have no clue what that might be yet! :)
> >
>
> Hmm. proportional-column-width() could indeed do the trick here. Too bad
> XSLT doesn't have aggregate functions min() or max(), but this can be worked
> around rather easily.
>
> Say your source XML looks like (--and you are actually using XML+XSLT to
> generate FO...)
>
>
>
> Some piece of text
> A slightly longer portion of text
>
>
> Longer text in first field
> Shorter text in field two
>
>
>
> Then, in XSLT, to construct a table offering the maximum field lengths
> mapped to column-widths, you could do something like (pseudo-code --well,
> almost... the code actually works):
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> column-width="{concat('proportional-column-width(',
> $vMax,')')}" />
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hope this gives you a clue...
>
>
> Greetz,
>
> Andreas
Thanks for the example.
vMax is a string length in this example though, right? Correct me if
I'm wrong, but I don't think proportional-column-width() will work with
a string length will it?
James
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Alternatives to auto table layout
> -Original Message- > From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] Erratum: > Too bad XSLT doesn't have aggregate functions min() or max(), but this > can be worked around rather easily. > Should be XSLT *1.0* XPath 2.0 (=> XSLT 2.0) *does* support these functions. Greetz, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Alternatives to auto table layout
> -Original Message- > From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] Hi, Before I forget to mention: > >
RE: Alternatives to auto table layout
> -Original Message- > From: James Earl [mailto:[EMAIL PROTECTED] > Hi, > I'm just curious to know what people have found works best for them as > an alternative to achieving somewhat auto table layout? I'm currently > trying to figure out what I should do. I've just started learning XSL > as a result of beginning to use FOP to try to automatically create a > catalogue from data stored within a MySQL database. > > The only idea I've had so far, was to use the maximum column lengths as > returned from PHP's mysql_fetch_field() to somehow formulate a > proportional-column-width() value for the column-widths. > > As for the formula... I have no clue what that might be yet! :) > Hmm. proportional-column-width() could indeed do the trick here. Too bad XSLT doesn't have aggregate functions min() or max(), but this can be worked around rather easily. Say your source XML looks like (--and you are actually using XML+XSLT to generate FO...) Some piece of text A slightly longer portion of text Longer text in first field Shorter text in field two Then, in XSLT, to construct a table offering the maximum field lengths mapped to column-widths, you could do something like (pseudo-code --well, almost... the code actually works): Hope this gives you a clue... Greetz, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Alternatives to auto table layout
Hi, I'm just curious to know what people have found works best for them as an alternative to achieving somewhat auto table layout? I'm currently trying to figure out what I should do. I've just started learning XSL as a result of beginning to use FOP to try to automatically create a catalogue from data stored within a MySQL database. The only idea I've had so far, was to use the maximum column lengths as returned from PHP's mysql_fetch_field() to somehow formulate a proportional-column-width() value for the column-widths. As for the formula... I have no clue what that might be yet! :) James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
