I think these words in documentation give an answer why your tiff images
are uncompressing by fop image loader:
TIFF
FOP can embed TIFF images without decompression into PDF, PostScript and
AFP if they have either CCITT T.4, CCITT T.6, or JPEG compression.
Otherwise, a TIFF-capable Image
TIFF can use JPEG compression, so it is likely that the issue is with JPEG
image handling even though it is a TIFF. But TwelveMonkeys also has an
imageio-tiff component so you can try both. Get the source from github,
build it (mvn clean install, I think) and place the needed jars in the FOP
lib
Hi,
Batik provides SVG REC 1.1 support.
Unfortunately, CMYK is introduced in SVG 1.2 WD (see [1]).
[1] http://www.w3.org/TR/SVGColor12/#icc-colors
2014-01-28 Matthias Reischenbacher matthias8...@gmx.at:
Hi,
I've noticed that JPEGs with DeviceCMYK color space, embedded in SVGs, are
converted
If the image is CMYK and you get gray scale output it means the image had
no color profile embedded. If you embed one FOP should convert it to RGB
unless you have an ImageIO library that can handle CMYK.
On Wed, Jan 29, 2014 at 7:06 AM, Valentina valent...@tp.rs wrote:
The reason I didn't want
My original image is in fact grayscale, but the grayscale original and the
rendered grayscale look different, that's the issue.
In that case, is it related to CMYK or something else?
2014-01-29 Luis Bernardo lmpmberna...@gmail.com
If the image is CMYK and you get gray scale output it means
I compiled the library.
Inside the lib directory, I now have the following:
avalon-framework
batik-all
commons-io
commons-logging
seralizer
twelvemonkeys-common-image
twelvemonkeys-common-io
twelvemonkeys-common-lang
twelvemonkeys-imageio-core
twelvemonkeys-imageio-jpeg
If you can share the image send it to this mailing list. Otherwise you can
send it to me and I can take a look. It is possible that the default image
loader is still being used, or something else is at play, but we will need
the image to check.
On Wed, Jan 29, 2014 at 1:07 PM, Valentina
Remove the image-loading section from fop.xconf, or at least the first
line (the second line can stay and may even be necessary). The way you have
it you may be giving preference to ImageLoaderImageIO (which is indeed the
default unless there is a native) over the twelvemonkeys image loader.
On
I tried both removing image-loading as well as just keeping the second
line. It did not have an observable effect.
Based on these cases, the conclusion appears to be that if I have an RGB
tiff image, the PDF renderer will work fine, but if non-RGB is used (16-bit
in my case), then it will not
You were right .
Thank You
--
View this message in context:
http://apache-fop.1065347.n5.nabble.com/altova-stylevision-fop-rtf-tp4825p39947.html
Sent from the FOP - Users mailing list archive at Nabble.com.
-
To unsubscribe,
10 matches
Mail list logo
