Jeremias Maerki wrote:
Thanks to Glen for raising the issue. The ideal approach is if Oleg
would pack up his TIFFRenderer and donate it to the ASF accompanied with
a software grant [1], but Oleg is a FOP committer and has a CLA on file.
So if Oleg attaches a ZIP with the sources for the
That's no problem, I think, because Batik has a TIFF encoder [3] already
in their codebase and we can move this code to the common area and use
that. Shouldn't be difficult to adjust.
Otherwise, I'd rather use ImageIO even if it's only available in JDKs
=1.4.
[3]
Glen Mazza wrote:
Yeah, Peter makes me want to do that sometimes
myself... ;)
Glen
Glen,
It's not difficult. I can give you some tips off-line if you like.
Peter
--
Peter B. West http://cv.pbw.id.au/
Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/
Jeremias Maerki wrote:
Relationship to which PDF renderer? The one that directly creates PDF
(PDFRenderer) or the one that creates PDF through JPS (normal
PrintRenderer as defined in the Wiki painting to a Graphics2D instance
provided by JPS) using a StreamPrintService? That's the two choices.
Peter,
Then my comment gave you a wrong impression: the Java2DRenderer is the
(abstract) base for all renderers that use the Java2D API for
rendering. The reference renderer is still the PDFRenderer, which
inherits from AbstractRenderer directly.
Renaud
No, definitely not. From what I learned from you, that's what you intend
to do. FOP pursues a different strategy. I believe that you can't get
the same quality PDF with all cool features with a PDF renderer that
operates with a Java2DRenderer as its base.
On 09.03.2005 12:34:20 Peter B. West
Renaud Richardet wrote:
Peter, let me answer you last mail [1] here:
You are right that the wiki is still vague about the detailled
implementation of the different renderers. Actually, I haven't started
to think about it until today. I will put my ideas tomorrow on the
wiki. I would be happy if
Renaud Richardet wrote:
Peter,
Then my comment gave you a wrong impression: the Java2DRenderer is the
(abstract) base for all renderers that use the Java2D API for
rendering. The reference renderer is still the PDFRenderer, which
inherits from AbstractRenderer directly.
Renaud
Renaud,
Understood.
I downloaded sun's codecs [2] that Oleg used in his TIFFRenderer.
Jeremias, you mean that we can legally just put those in the FOP-code?
Following codecs are included in [2]:
- TIFF
- JPEG
- PNG
- BMP
So it should be possible to create a renderer for each of this file
formats. But do we need them
On 09.03.2005 12:51:11 Renaud Richardet wrote:
I downloaded sun's codecs [2] that Oleg used in his TIFFRenderer.
Jeremias, you mean that we can legally just put those in the FOP-code?
This would have to be checked out. I'd rather not, especially when we
have PNG and TIFF codecs under Apache
Sounds to me like 2) is the way to go right now. This would mean minimal
recreation of vertical boxes in case of changing available IPD. Sure,
this is an exotic case but XSL-FO makes it possible, therefore we must
be prepared for it.
Thanks for the hints and the helpful example.
On 08.03.2005
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
Otherwise, I'd rather use ImageIO even if it's
only available in JDKs
=1.4.
I thought FOP should be 1.3 compilant [3]? So how
do we go around that?
That's right. But nothing stops us from providing
additional code that's
JDK 1.4
Jeremias Maerki wrote:
That's no problem, I think, because Batik has a TIFF encoder [3] already
in their codebase and we can move this code to the common area and use
that. Shouldn't be difficult to adjust.
Last time I checked Batik's TIFF encoder was kinda limited WRT some TIFF
compressions, and
Jeremias Maerki wrote:
I would like to suggest that you implement TIFF and PNG output using
Batik's codecs.
Yep, that's the best solution. But please check that Batik's TIFF codec
supports all TIFF compressions Sun's codec does. 2 years ago it was sort
of limited, particularly wrt fax
Yes, please, because it's a lot easier to handle inside an IDE. You
simply define an additional source folder if you're on JDK 1.4, and you
don't get compile error on JDK 1.3.
On 09.03.2005 16:34:39 Glen Mazza wrote:
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
Otherwise, I'd rather use
Ah, there's the catch. Yes, CCITT4 is particularly interesting which is
not supported by the code in Batik. But still, I think we don't have to
support everything under JDK 1.3. I wonder how many people under JDK 1.3
would need that particular compression type. And if they really do they
then have
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
Ah, there's the catch. Yes, CCITT4 is particularly
interesting which is
not supported by the code in Batik. But still, I
think we don't have to
I don't think we have to
support everything under JDK 1.3.
Or anything, for that matter. 1.3 users
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
RFC 2045 [1] says this:
(1) Private values (starting with X-) may be
defined
bilaterally between two cooperating
agents without
outside registration or standardization.
Such values
cannot be registered or
Le 9 mars 05, à 01:12, Glen Mazza a écrit :
...[Thanks also to Bertrand for sending Renaud our way.
This is the second quality developer--Peter Herweg
being the other--that we have gotten from him since
I've been on this project.]..
You're welcome - and you don't even know how many people I sent
19 matches
Mail list logo
