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: fo:table-column column-width=proportional-column-width(1) / fo:table-column column-width=proportional-column-width(5) / 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 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: fo:table-column column-width=proportional-column-width(1) / fo:table-column column-width=proportional-column-width(5) / 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
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 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
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 -- green/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: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
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
-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: snip / 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: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: snip / 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: 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
-Original Message-
From: James Earl [mailto:[EMAIL PROTECTED]
Hi,
snip /
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...)
root
record
field index=1Some piece of text/field
field index=2A slightly longer portion of text/field
/record
record
field index=1Longer text in first field/field
field index=2Shorter text in field two/field
/record
/root
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):
xsl:template match=root
fo:table table-layout=fixed width=100%
!-- use the first row as basis; we only need the first row
to determine the number of columns (see CSS spec) --
xsl:apply-templates select=record[1]/field mode=col-create /
fo:table-body
xsl:apply-templates select=record mode=row-create /
/fo:table-body
/fo:table
/xsl:template
xsl:template match=field mode=col-create
!-- create a variable to contain the maximum field-width ... --
xsl:variable name=vMax
!-- iterate over all fields with the same @index ... --
xsl:for-each select=/*/record/[EMAIL PROTECTED]()/@index]
!-- sort in descending order --
xsl:sort select=string-length() order=descending /
!-- the first one in sorted order is the one we need --
xsl:if test=position()=1
xsl:value-of select=string-length() /
/xsl:if
/xsl:for-each
/xsl:variable
!-- ... and use this maximum for prop-col-width --
fo:table-column column-number=[EMAIL PROTECTED]
column-width={concat('proportional-column-width(',
$vMax,')')} /
/xsl:template
xsl:template match=record mode=row-create
fo:table-row
xsl:for-each select=field
fo:table-cell column-number=[EMAIL PROTECTED]
fo:block
xsl:value-of select=. /
/fo:block
/fo:table-cell
/fo:table-row
/xsl:template
Hope this gives you a clue...
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: !-- ... and use this maximum for prop-col-width -- fo:table-column column-number=[EMAIL PROTECTED] The column-number property is used here, but is still unimplemented in FOP 0.20.5 (it *will* be in the next version, though... it partly is in my local version anyway :) A bit of fine-tuning still required ) Cheers, 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] 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
On Tue, 2004-05-25 at 16:08, Andreas L. Delmelle wrote:
-Original Message-
From: James Earl [mailto:[EMAIL PROTECTED]
Hi,
snip /
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...)
root
record
field index=1Some piece of text/field
field index=2A slightly longer portion of text/field
/record
record
field index=1Longer text in first field/field
field index=2Shorter text in field two/field
/record
/root
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):
xsl:template match=root
fo:table table-layout=fixed width=100%
!-- use the first row as basis; we only need the first row
to determine the number of columns (see CSS spec) --
xsl:apply-templates select=record[1]/field mode=col-create /
fo:table-body
xsl:apply-templates select=record mode=row-create /
/fo:table-body
/fo:table
/xsl:template
xsl:template match=field mode=col-create
!-- create a variable to contain the maximum field-width ... --
xsl:variable name=vMax
!-- iterate over all fields with the same @index ... --
xsl:for-each select=/*/record/[EMAIL PROTECTED]()/@index]
!-- sort in descending order --
xsl:sort select=string-length() order=descending /
!-- the first one in sorted order is the one we need --
xsl:if test=position()=1
xsl:value-of select=string-length() /
/xsl:if
/xsl:for-each
/xsl:variable
!-- ... and use this maximum for prop-col-width --
fo:table-column column-number=[EMAIL PROTECTED]
column-width={concat('proportional-column-width(',
$vMax,')')} /
/xsl:template
xsl:template match=record mode=row-create
fo:table-row
xsl:for-each select=field
fo:table-cell column-number=[EMAIL PROTECTED]
fo:block
xsl:value-of select=. /
/fo:block
/fo:table-cell
/fo:table-row
/xsl:template
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]
