Re: Good job! / Re: Integration of TIFFRenderer in FOP

[Bertrand Delacretaz]

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 your 
way that did not make it ;-)

(just kidding - I'm happy to contribute, even if it's just helping 
convince people to jump in)

-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

Re: cvs commit: xml-fop/src/java/org/apache/fop/render/awt/viewer PreviewDialog.java

[Glen Mazza]

--- 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 standardized.
> 
> So to be on the safe side we would need to rename
> "application/awt" to
> "application/X-awt".
> 

Sounds good--and acceptable for purists as well.

Glen


> [1] http://www.faqs.org/rfcs/rfc2045.html
> 

Re: Good job! / Re: Integration of TIFFRenderer in FOP

[Glen Mazza]

--- 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 can remain on
0.20.5 IMO, optionally downloading Oleg's TIFF patch
if they need to.  

Glen

Re: Good job! / Re: Integration of TIFFRenderer in FOP

[Jeremias Maerki]

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 several examples on how to adjust the bitmap renderer for
themselves. And a additional JAI implementation is certainly not a big
deal after we have the first one.

On 09.03.2005 16:38:33 Oleg Tkachenko wrote:
> 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 that's the reason I used the codec from Sun. That 
> would be really nice to fix Batik's codec instead.


Jeremias Maerki

Re: Good job! / Re: Integration of TIFFRenderer in FOP

[Jeremias Maerki]

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 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 dependent as long as it's not core
> > functionality and it's in a
> > separate directory (src/java-1.4).
> > 
> 
> BTW, does it have to be in a separate directory?  Can
> we keep it in the directory it would otherwise be in
> if FOP were 1.4-based but somehow alter the Ant
> scripts to help the 1.3-only users?
> 
> Glen



Jeremias Maerki

Re: Good job! / Re: Integration of TIFFRenderer in FOP

[Oleg Tkachenko]

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 compressions.

I have the impression that he wants to. There are simply a few issues to
look at. Looking at possible licensing issue I'd suggest Oleg simply
donates his own classes (not the codec) to the FOP project by applying
the Apache license and posting them as a Bugzilla issue.
Ok, I will anyway, just to be at least a bit helpful here :)
--
Oleg Tkachenko
http://blog.tkachenko.com
Multiconn Technologies, Israel

Re: Good job! / Re: Integration of TIFFRenderer in FOP

[Oleg Tkachenko]

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 that's the reason I used the codec from Sun. That 
would be really nice to fix Batik's codec instead.

--
Oleg Tkachenko
http://blog.tkachenko.com
Multiconn Technologies, Israel

Re: Good job! / Re: Integration of TIFFRenderer in FOP

[Glen Mazza]

--- 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 dependent as long as it's not core
> functionality and it's in a
> separate directory (src/java-1.4).
> 

BTW, does it have to be in a separate directory?  Can
we keep it in the directory it would otherwise be in
if FOP were 1.4-based but somehow alter the Ant
scripts to help the 1.3-only users?

Glen

Re: Skype-conference on page-breaking?

[Jeremias Maerki]

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 19:43:57 Luca Furini wrote:
> Jeremias Maerki wrote:
> 
> > Luca, do you think your total-fit approach may be written in a way to
> > handle changing available IPDs and that look-ahead can be disabled to
> > improve processing speed at the cost of optimal break decisions?
> 
> I think that a first fit algorithm could be implemented in two different ways:
> 1) wait until the list of elements representing a whole page-sequence is
>collected, and call findBreakingPoints(); this method will call a
>different considerLegalBreak() method, much simpler and faster than
>the knuth's one.
> 2) start building pages little by little: the FlowLM returns elements to
>the PageLM as soon as one of its own child returns them
> 
> Alternative 1) is much like the total fit algorithm: breaks are computed
> at the end of each page-sequence; even if the evaluation method is much
> faster than Knuth's one, there could still be a long wait in order to get
> the whole list.
> 
> With alternative 2) the PageLM would behave much the same as it now does:
> as soon as a page is filled, it is possible to call addAreas. Note that
> the last elements in the partial sequence cannot be considered as feasible
> break. For example, if there is a block which creates 6 lines, the
> sequence will be something like:
>  box
>  box
>  penalty(not infinite)
>  box
>  penalty(not infinite)
>  box
>  box
> and the evaluation must stop at the second penalty; only when some
> following elements are known it will be possible to decide whether the
> last two lines could be at the end of a page.
> 
> If the IPD is always the same, I think the two alternatives are
> equivalent, and the first one is "better" because it just needs a
> different considerLegalBreak() method; as the output file cannot be
> printed until the end of the process, the only advantage of 2) could be
> memory usage.
> 
> > That's the part where I have a big question mark about changing
> > available IPD. We may have to have a check that figures out if the
> > available IPD changes within a page-sequence by inspecting the
> > page-masters. That would allow us to switch automatically between
> > total-fit and best-fit or maybe even first-fit.
> 
> If the IPD changes, I fear 2) must be necessarily used: if a block is
> split between pages with different ipd, only a few lines need to be
> recreated.
> Using 1), the LineLM should know how wide the lines are, but this cannot
> be known as page breaking has not yet started.
> 
> The check could be done before starting the layout phase: if there is a
> change, 2) is used, otherwise 1).
> Maybe, the check could be even more sophisticated: for example, if the
> first page is different, but the following are equally wide, we could use
> 2) to create the first page and then switch to 1).
> 
> > A remaining question
> > mark is with side-floats as they influence the available IPD on a
> > line-to-line basis.
> 
> This is a question mark for me too! :-)
> 
> > One thing for a deluxe strategy for book-style
> > documents is certainly alignment of lines between facing pages. But
> > that's something that's not important at the moment.
> 
> I have created and implemented a new property right about this! :-)
> 
> > I'd be very interested to hear what you think about the difficulty of
> > changing available IPD. The more I think about it, however, the more I
> > think the total-fit model gets too complicated for what we/I need right
> > now. But I'm unsure here.
> 
> If changing ipd is really important and not just a theorical possibility,
> we could start implementing 2, and later add the check and the algorithm
> 1: the getNextKnuthElements() in the block-level LM could be used in both
> cases.
> 
> Regards
> Luca
> 
> 



Jeremias Maerki

Re: Good job! / Re: Integration of TIFFRenderer in FOP

[Jeremias Maerki]

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 license already available.

> 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 all?
> Do we also need GIF encoding ([2] only supports GIF decoding) . If
> yes, we'll have to use other libraries like ACME Labs GIF encoder
> (right?)

I would like to suggest that you implement TIFF and PNG output using
Batik's codecs.

> Besides, I haven't understand yet if Oleg will donate his code to Apache.

I have the impression that he wants to. There are simply a few issues to
look at. Looking at possible licensing issue I'd suggest Oleg simply
donates his own classes (not the codec) to the FOP project by applying
the Apache license and posting them as a Bugzilla issue. You can then
use these classes to implement output via Batik's codecs. Or you simply
reimplement the same functionality without copy/paste. :-) As he said,
it's only a thin wrapper. The key is to have codecs with the right
licensing.

> > 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 dependent as long as it's not core functionality and it's in a
separate directory (src/java-1.4).

> Regards,
> Renaud
> 
> [3] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=1332332



Jeremias Maerki

Re: Good job! / Re: Integration of TIFFRenderer in FOP

[Renaud Richardet]

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 all?
Do we also need GIF encoding ([2] only supports GIF decoding) . If
yes, we'll have to use other libraries like ACME Labs GIF encoder
(right?)

Besides, I haven't understand yet if Oleg will donate his code to Apache.

> 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?

Regards,
Renaud

[3] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=1332332

Re: Integration of TIFFRenderer in FOP

[Peter B. West]

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.
Peter
--
Peter B. West 
Folio  

Re: Good job! / Re: Integration of TIFFRenderer in FOP

[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 you could put your inputs there, too.
Renaud,
I don't have particular input.  I haven't given the rendering any 
detailed thought at all, apart from the perception fostered by the 
presence of PDFGraphics2D, PDFGraphicsConfiguration, PDFGraphicsDevice 
and similar classes in other contexts, that a mapping of the Area tree 
to Java Graphics2D output could be translated very directly into PDF 
(and other formats).  If that necessarily involves the JPS, so be it.

In order to flesh these notions out, I will be taking maximum advantage 
of the expertise of others, including yourself.  In the meantime, I 
continue to work on the generation of the Area tree.

Peter
--
Peter B. West 
Folio  

Re: Integration of TIFFRenderer in FOP

[Jeremias Maerki]

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 wrote:
> That will be extremely useful.  However, I was trying to clarify the 
> situation of PDFRenderer.  The impression I got from Renaud's comment 
> was that the Java2DRenderer was to be the basis of all renderers.  Hence 
> my interest.



Jeremias Maerki

Re: Integration of TIFFRenderer in FOP

[Renaud Richardet]

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

Re: Integration of TIFFRenderer in FOP

[Peter B. West]

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.
Obviously, you will be taking the latter approach. If you wait a bit
(until the common components area is set up) you'll have a neatly
separated package to create PDF using JPS because I'll be publishing my
proof-of-concept JPS StreamPrintService which you can build on.

Hmm, this gives me another thing to talk about over in XML Graphics
General.
On 09.03.2005 00:53:16 Peter B. West wrote:
This approach is obviously of interest to me, and I will follow 
developments closely.  The wiki page is very general.  If the 
Java2DRenderer is to be the "(abstract) technical foundation", what will 
the relationship to the concrete PDF renderer be?  The wiki is vague on 
this point.
Jeremias,
That will be extremely useful.  However, I was trying to clarify the 
situation of PDFRenderer.  The impression I got from Renaud's comment 
was that the Java2DRenderer was to be the basis of all renderers.  Hence 
my interest.

Peter
--
Peter B. West 
Folio  

Re: Integration of TIFFRenderer in FOP

[Peter B. West]

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 
Folio  

Re: Good job! / Re: Integration of TIFFRenderer in FOP

[Jeremias Maerki]

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] 
http://cvs.apache.org/viewcvs.cgi/xml-batik/sources/org/apache/batik/ext/awt/image/codec/tiff/

On 09.03.2005 11:30:51 Oleg Tkachenko wrote:
> 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 TIFFRenderer (ALv2
> > already applied) to a Bugzilla entry along with a note that we may
> > include it in FOP, that's good enough for me. It's not that the thing is
> > a big application in itself even though some people would argue works
> > like Renaud's AWT patch and Oleg's TIFFRenderer must go/run through the
> > Incubator.
> 
> To make things even more complicated, TIFFRenderer is just a thin 
> wrapper around some weird licensed [1] Sun's codec sources, called "Java 
> Advanced Imaging API 1.1.1 Sample Source" [2], which includes some 
> provisional bits of JAI. I'm not sure if we want to use it. What about 
> using full-blown JAI?
> 
> [1] 
> http://www.tkachenko.com/fop/JAI_1.1.1_sample_io_sourcecodelic.10_23_01.txt
> [2] http://java.sun.com/developer/sampsource/jai/
> -- 
> Oleg Tkachenko
> http://blog.tkachenko.com
> Multiconn Technologies, Israel



Jeremias Maerki

Re: Good job! / Re: Integration of TIFFRenderer in FOP

[Oleg Tkachenko]

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 TIFFRenderer (ALv2
already applied) to a Bugzilla entry along with a note that we may
include it in FOP, that's good enough for me. It's not that the thing is
a big application in itself even though some people would argue works
like Renaud's AWT patch and Oleg's TIFFRenderer must go/run through the
Incubator.
To make things even more complicated, TIFFRenderer is just a thin 
wrapper around some weird licensed [1] Sun's codec sources, called "Java 
Advanced Imaging API 1.1.1 Sample Source" [2], which includes some 
provisional bits of JAI. I'm not sure if we want to use it. What about 
using full-blown JAI?

[1] 
http://www.tkachenko.com/fop/JAI_1.1.1_sample_io_sourcecodelic.10_23_01.txt
[2] http://java.sun.com/developer/sampsource/jai/
--
Oleg Tkachenko
http://blog.tkachenko.com
Multiconn Technologies, Israel