You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Jeff Laughlin <je...@gmail.com> on 2008/10/29 19:37:15 UTC
Color in JPGs comes out too dark
Howdy,
For the first time I tried putting some JPGs into my DocBook file and when I
FOP it into a PDF the colors are appearing much to dark on my screen. I
suspect a color management issue and I have searched on the list archive but
I haven't found a solution, I was hoping somebody might be able to offer a
suggestion.
How it should look: http://n1ywb.com/hiq/images/IMG_0494.JPG
How it looks in Reader: http://n1ywb.com/hiq/hiqbadcolor.jpg
In KPDF it looks good (IE no color management).
My PDF file: http://n1ywb.com/hiq/manual.pdf
The whole project: http://n1ywb.com/hiq/
Using GIMP I've checked and the images are assigned to sRGB color space.
I've tried screwing around with the color space settings and also saving as
PNG instead of JPG and it all looks the same in Reader.
Any help would be greatly appreciated.
--
73 de n1ywb
Re: Question on page wrap
Posted by Sheldon Glickler <sh...@thevillages.net>.
Andreas Delmelle wrote:
> On Nov 1, 2008, at 13:08, Sheldon Glickler wrote:
>
>> Andreas Delmelle wrote:
>>> On Oct 31, 2008, at 20:03, Sheldon Glickler wrote:
>>>> I have a report that has an arbitrary number of columns. The number
>>>> of columns is such that it would go beyond the page width. Also the
>>>> number of rows is such that it goes beyond the page height.
>>> Problematic. XSL-FO 1.1 knows no 'vertical' page-breaks. The table
>>> will only be broken in block-progression-direction (if there is no
>>> keep-property telling us otherwise), and clipped if it doesn't fit
>>> the page in inline-progression-direction.
>>> None of your proposed fallbacks are possible in XSL-FO, IIRC. Not
>>> only in FOP, but any implementation...
>>> Cheers
>>> Andreas
>>
>> Wow! That is **some** major drawback.
>
> On the 'bright' side, I know this particular feature to be among the
> XSL-FO 2.0 requirements...
>
>> First, I am using .20-5 (and cannot upgradee). I had envisioned doing
>> something with coding. I know how wide my columns are and how many
>> rows will fit on a page.
>>
>> I imagine I could use two loops, one for horizontal and one for
>> vertical. That would mean, for the horizontal, writing the header
>> block as Header1_1, Header1_2, etc. I would then have in the XSL
>> templates for Header1_1, FirstColumns1_1, Body1_1, Header1_2,
>> FirstColumns1_2, Body1_2, etc. where FirstColumns1_2 was a repeat of
>> FirstColumns1_1.
>>
>> If there were a "page break" instruction, I could then limit the
>> Body1, Body2 to those lines that fit, and then repeat with Header2_1,
>> FirstColumns2_1, Body2_1, Header2_2, FirstColumns2_2, Body2_2, etc.
>> where Header2_1 was a repeat of Header1_1 and FirstColumns2_2 was a
>> repeat of FirstColumns2_1and so on.
>
> You mean, something like: break-before="page" or break-after="page"?
> (see: http://www.w3.org/TR/xsl/#d0e26492)
>
> That was along the lines I was thinking this issue /might/ be solvable:
> pre-compute the breaks and insert them as forced breaks in the XSLT. You
> would have to split the content into multiple tables so that the FO
> processor would always get tables that fit entirely into one page.
Ok, it seems I need a line like:
<xsl:attribute name="break-after">page</xsl:attribute>
inside the <fo:table>. The problem now is that it goes in the xsl, but
I do all my calculations to generate the xml, not the xsl. Would this work?
In the xsl I would have:
<xsl:template match-"page_1">
<xsl:apply-templates select="header" />
<xsl:apply-templates select="data_columns" />
<xsl:apply-templates select="break_page">
</xsl:template>
<xsl:template match="break_page">
<fo:table>
<xsl:attribute name="break-after">page</xsl:attribute>
</fo:table>
</xsl:template>
and in the xml forcing a page break with
<break_page></break_page>
....or not even adding anything to the xml at all? The pages (_1 to
_20) have already been determined in the xml by column and row count.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Question on page wrap
Posted by Andreas Delmelle <an...@telenet.be>.
On Nov 1, 2008, at 13:08, Sheldon Glickler wrote:
> Andreas Delmelle wrote:
>> On Oct 31, 2008, at 20:03, Sheldon Glickler wrote:
>>> I have a report that has an arbitrary number of columns. The
>>> number of columns is such that it would go beyond the page
>>> width. Also the number of rows is such that it goes beyond the
>>> page height.
>> Problematic. XSL-FO 1.1 knows no 'vertical' page-breaks. The table
>> will only be broken in block-progression-direction (if there is no
>> keep-property telling us otherwise), and clipped if it doesn't fit
>> the page in inline-progression-direction.
>> None of your proposed fallbacks are possible in XSL-FO, IIRC. Not
>> only in FOP, but any implementation...
>> Cheers
>> Andreas
>
> Wow! That is **some** major drawback.
On the 'bright' side, I know this particular feature to be among the
XSL-FO 2.0 requirements...
> First, I am using .20-5 (and cannot upgradee). I had envisioned
> doing something with coding. I know how wide my columns are and
> how many rows will fit on a page.
>
> I imagine I could use two loops, one for horizontal and one for
> vertical. That would mean, for the horizontal, writing the header
> block as Header1_1, Header1_2, etc. I would then have in the XSL
> templates for Header1_1, FirstColumns1_1, Body1_1, Header1_2,
> FirstColumns1_2, Body1_2, etc. where FirstColumns1_2 was a repeat
> of FirstColumns1_1.
>
> If there were a "page break" instruction, I could then limit the
> Body1, Body2 to those lines that fit, and then repeat with
> Header2_1, FirstColumns2_1, Body2_1, Header2_2, FirstColumns2_2,
> Body2_2, etc. where Header2_1 was a repeat of Header1_1 and
> FirstColumns2_2 was a repeat of FirstColumns2_1and so on.
You mean, something like: break-before="page" or break-after="page"?
(see: http://www.w3.org/TR/xsl/#d0e26492)
That was along the lines I was thinking this issue /might/ be
solvable: pre-compute the breaks and insert them as forced breaks in
the XSLT. You would have to split the content into multiple tables so
that the FO processor would always get tables that fit entirely into
one page.
The downside is that this obviously only works if you know in advance
precisely how much of the content can be put in one page (bypassing
much of the layout-computations, by performing them yourself
beforehand). This could be feasible if all your pages are guaranteed
to use the same page-master, and all rows are the same height. As
soon as you have a mixture of one-line and multi-line rows/cells, it
will already become increasingly difficult to keep track of...
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Question on page wrap
Posted by Sheldon Glickler <sh...@thevillages.net>.
Andreas Delmelle wrote:
> On Oct 31, 2008, at 20:03, Sheldon Glickler wrote:
>
>> I have a report that has an arbitrary number of columns. The number
>> of columns is such that it would go beyond the page width. Also the
>> number of rows is such that it goes beyond the page height.
>
> Problematic. XSL-FO 1.1 knows no 'vertical' page-breaks. The table will
> only be broken in block-progression-direction (if there is no
> keep-property telling us otherwise), and clipped if it doesn't fit the
> page in inline-progression-direction.
>
> None of your proposed fallbacks are possible in XSL-FO, IIRC. Not only
> in FOP, but any implementation...
>
>
> Cheers
>
> Andreas
Wow! That is **some** major drawback.
First, I am using .20-5 (and cannot upgradee). I had envisioned doing
something with coding. I know how wide my columns are and how many rows
will fit on a page.
I imagine I could use two loops, one for horizontal and one for
vertical. That would mean, for the horizontal, writing the header block
as Header1_1, Header1_2, etc. I would then have in the XSL templates
for Header1_1, FirstColumns1_1, Body1_1, Header1_2, FirstColumns1_2,
Body1_2, etc. where FirstColumns1_2 was a repeat of FirstColumns1_1.
If there were a "page break" instruction, I could then limit the Body1,
Body2 to those lines that fit, and then repeat with Header2_1,
FirstColumns2_1, Body2_1, Header2_2, FirstColumns2_2, Body2_2, etc.
where Header2_1 was a repeat of Header1_1 and FirstColumns2_2 was a
repeat of FirstColumns2_1and so on.
All of that would simply mean enclosing those sections in similarly
named (as above), but different xml blocks and having all those
templates called by the xsl. For simplicity, I would have to add one
more level to the structure so that, for example, all the Headerx_y
templates would just invoke the Header template which is written for an
arbitrary number of columns. Likewise for the body stuff.
I can code all of this to make it semi-general, and it should work. It
is predicated, however, on being able to force a page break. It alos
seems rather cumbersome, as there should be some sort of "wrap"
instruction.
Since what I said above might be a little confusing, I have drawn a
picture below for one expansion horizontally and one vertically
illustrating my thinking. Again, this is predicated upon having a page
break command.
PDF
===
--------- Header1_1 ----- --------- Header1_2 -----
FirstColumns1_1 Body1_1 FirstColumns1_2 Body1_2
--------- Header2_1 ----- --------- Header2_2 -----
FirstColumns2_1 Body2_1 FirstColumns2_2 Body2_2
XSL
===
<xsl:apply-templates select="Header1_1" />
<xsl:apply-templates select="FirstColumns1_1" />
<xsl:apply-templates select="Body1_1" />
<xsl:apply-templates select="Header1_2" />
<xsl:apply-templates select="FirstColumns1_2" />
<xsl:apply-templates select="Body1_2" />
<xsl:apply-templates select="Header2_1" />
<xsl:apply-templates select="FirstColumns2_1" />
<xsl:apply-templates select="Body2_1" />
<xsl:apply-templates select="Header2_2" />
<xsl:apply-templates select="FirstColumns2_2" />
<xsl:apply-templates select="Body2_2" />
<xsl:template match="Header1_1">
<xsl:apply-templates select="Header" />
<xsl:template match="Header1_2">
<xsl:apply-templates select="Header" />
<xsl:template match="Header2_1">
<xsl:apply-templates select="Header" />
<xsl:template match="Header2_2">
<xsl:apply-templates select="Header" />
and so on.
XML
===
<Header1_1><Header> stuff1 </Header></Header1_1>
<Header1_2><Header> stuff2 </Header></Header1_2>
<Header2_1><Header> stuff1 </Header></Header2_1>
<Header2_2><Header> stuff2 </Header></Header2_2>
and so on
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Question on page wrap
Posted by Andreas Delmelle <an...@telenet.be>.
On Oct 31, 2008, at 20:03, Sheldon Glickler wrote:
> I have a report that has an arbitrary number of columns. The
> number of columns is such that it would go beyond the page width.
> Also the number of rows is such that it goes beyond the page height.
Problematic. XSL-FO 1.1 knows no 'vertical' page-breaks. The table
will only be broken in block-progression-direction (if there is no
keep-property telling us otherwise), and clipped if it doesn't fit
the page in inline-progression-direction.
None of your proposed fallbacks are possible in XSL-FO, IIRC. Not
only in FOP, but any implementation...
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Question on page wrap
Posted by Sheldon Glickler <sh...@thevillages.net>.
I have a report that has an arbitrary number of columns. The number of
columns is such that it would go beyond the page width. Also the number
of rows is such that it goes beyond the page height.
I have five columns that are somewhat fixed in the beginning and then
the arbitrary number of data columns. There are also three rows of
header data.
(A) The ideal solution would be to have the header data and the first
five columns on succeeding pages.
(B) The secondary fallback would be to have the have the header and
overflow data on succeeding pages.
(c) A third fallback would be to have the columns and overflow data on
succeeding pages
(D) A final fallback would be to have just the overflow data appear on
succeeding pages.
That last one, D, resembles what happens when you simply print from
Excel when there are too many columns for a page and there are too many
rows for a page. B and C are where like when you like the rows or the
columns.
Can anyone help me here by telling me what I have to do?
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Color in JPGs comes out too dark
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Ignore that. I should have looked at the PDF myself and like Andreas, I
don't see that effect in Acrobat Reader on WinXP. Maybe a
Adobe/Linux-related problem. Definitely not Bug 45809. Sorry for the
noise.
On 29.10.2008 20:59:17 Jeremias Maerki wrote:
> Could be related to: https://issues.apache.org/bugzilla/show_bug.cgi?id=45809
>
> On 29.10.2008 20:37:15 Jeff Laughlin wrote:
> > Howdy,
> >
> > For the first time I tried putting some JPGs into my DocBook file and when I
> > FOP it into a PDF the colors are appearing much to dark on my screen. I
> > suspect a color management issue and I have searched on the list archive but
> > I haven't found a solution, I was hoping somebody might be able to offer a
> > suggestion.
> >
> > How it should look: http://n1ywb.com/hiq/images/IMG_0494.JPG
> > How it looks in Reader: http://n1ywb.com/hiq/hiqbadcolor.jpg
> > In KPDF it looks good (IE no color management).
> > My PDF file: http://n1ywb.com/hiq/manual.pdf
> > The whole project: http://n1ywb.com/hiq/
> >
> > Using GIMP I've checked and the images are assigned to sRGB color space.
> > I've tried screwing around with the color space settings and also saving as
> > PNG instead of JPG and it all looks the same in Reader.
> >
> > Any help would be greatly appreciated.
> >
> > --
> > 73 de n1ywb
>
>
>
>
> Jeremias Maerki
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Color in JPGs comes out too dark
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Could be related to: https://issues.apache.org/bugzilla/show_bug.cgi?id=45809
On 29.10.2008 20:37:15 Jeff Laughlin wrote:
> Howdy,
>
> For the first time I tried putting some JPGs into my DocBook file and when I
> FOP it into a PDF the colors are appearing much to dark on my screen. I
> suspect a color management issue and I have searched on the list archive but
> I haven't found a solution, I was hoping somebody might be able to offer a
> suggestion.
>
> How it should look: http://n1ywb.com/hiq/images/IMG_0494.JPG
> How it looks in Reader: http://n1ywb.com/hiq/hiqbadcolor.jpg
> In KPDF it looks good (IE no color management).
> My PDF file: http://n1ywb.com/hiq/manual.pdf
> The whole project: http://n1ywb.com/hiq/
>
> Using GIMP I've checked and the images are assigned to sRGB color space.
> I've tried screwing around with the color space settings and also saving as
> PNG instead of JPG and it all looks the same in Reader.
>
> Any help would be greatly appreciated.
>
> --
> 73 de n1ywb
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Color in JPGs comes out too dark
Posted by Andreas Delmelle <an...@telenet.be>.
On Oct 29, 2008, at 19:48, Andreas Delmelle wrote:
> On Oct 29, 2008, at 19:37, Jeff Laughlin wrote:
>
>> <snip />
>> My PDF file: http://n1ywb.com/hiq/manual.pdf
>
> FWIW: Looks good too on my end, in Adobe Reader 9 for OS X.
Same in versions 7.0.7 and 8.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Color in JPGs comes out too dark
Posted by Andreas Delmelle <an...@telenet.be>.
On Oct 29, 2008, at 19:37, Jeff Laughlin wrote:
Hi
> For the first time I tried putting some JPGs into my DocBook file
> and when I FOP it into a PDF the colors are appearing much to dark
> on my screen. I suspect a color management issue and I have
> searched on the list archive but I haven't found a solution, I was
> hoping somebody might be able to offer a suggestion.
>
> How it should look: http://n1ywb.com/hiq/images/IMG_0494.JPG
> How it looks in Reader: http://n1ywb.com/hiq/hiqbadcolor.jpg
> In KPDF it looks good (IE no color management).
> My PDF file: http://n1ywb.com/hiq/manual.pdf
FWIW: Looks good too on my end, in Adobe Reader 9 for OS X.
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org