You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-commits@xmlgraphics.apache.org by je...@apache.org on 2009/04/03 09:44:09 UTC
svn commit: r761554 - in /xmlgraphics/fop/trunk:
src/java/org/apache/fop/render/print/PrintRenderer.java status.xml
Author: jeremias
Date: Fri Apr 3 07:44:09 2009
New Revision: 761554
URL: http://svn.apache.org/viewvc?rev=761554&view=rev
Log:
Fixed a bug that left the PrintRenderer unconfigured even if a configuration was specified for "application/X-fop-print".
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/print/PrintRenderer.java
xmlgraphics/fop/trunk/status.xml
Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/render/print/PrintRenderer.java
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/print/PrintRenderer.java?rev=761554&r1=761553&r2=761554&view=diff
==============================================================================
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/render/print/PrintRenderer.java (original)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/render/print/PrintRenderer.java Fri Apr 3 07:44:09 2009
@@ -25,6 +25,7 @@
import java.util.Map;
import org.apache.fop.apps.FOUserAgent;
+import org.apache.fop.apps.MimeConstants;
/**
* Renderer that prints through java.awt.PrintJob.
@@ -70,6 +71,11 @@
printerJob.setPageable(this);
}
+ /** {@inheritDoc} */
+ public String getMimeType() {
+ return MimeConstants.MIME_FOP_PRINT;
+ }
+
private void initializePrinterJob() {
if (this.printerJob == null) {
printerJob = PrinterJob.getPrinterJob();
Modified: xmlgraphics/fop/trunk/status.xml
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/status.xml?rev=761554&r1=761553&r2=761554&view=diff
==============================================================================
--- xmlgraphics/fop/trunk/status.xml (original)
+++ xmlgraphics/fop/trunk/status.xml Fri Apr 3 07:44:09 2009
@@ -58,6 +58,10 @@
documents. Example: the fix of marks layering will be such a case when it's done.
-->
<release version="FOP Trunk" date="TBD">
+ <action context="Renderers" dev="JM" type="fix">
+ Fixed a bug that left the PrintRenderer unconfigured even if a configuration was
+ specified for "application/X-fop-print".
+ </action>
<action context="Renderers" dev="JM" type="fix" fixes-bug="46882" due-to="Yegor Kozlov">
Fixed the handling of CMYK colors in PDFGraphics2D.
</action>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org
Re: svn commit: r761554 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/print/PrintRenderer.java
status.xml
Posted by Vincent Hennebert <vh...@gmail.com>.
Jeremias Maerki wrote:
> Hi Vincent,
>
> well, the "print" renderer doesn't really have an official MIME type.
> The result could be paper, PDF, PostScript or whatever. I've given it a
> pseudo MIME type "application/X-fop-print" just so configuration works
> for this renderer, too. So it really depends how you look at it.
>
> But I've just noticed that there's another renderer that really doesn't
> have a MIME type: Java2DRenderer. So, if anyone subclassed
> Java2DRenderer to paint pages in their own Swing application they are
> going to find themselves with a compile error next time they upgrade.
> Actually a reason to put the getMimeType() back in AbstractRenderer.
> However, they have to implement getMimeType() anyway if they want to
> configure the renderer through the XML configuration so probably no harm
> done.
Ok, so the mime type is essentially used for configuration purpose, in
which case leaving it to null simply means that the renderer does not
need that feature.
It makes sense then to have a default implementation in
AbstractRenderer. OTOH, not defining one forces to think about that when
implementing a renderer. Maybe safer.
Thanks for the explanations,
Vincent
> On 03.04.2009 12:31:32 Vincent Hennebert wrote:
>> Hi Jeremias,
>>
>> Jeremias Maerki wrote:
>>> Hi Vincent,
>>>
>>> Removing getMimeType() on AbstractRenderer is ok although that could
>>> break someone else's renderer (risk very slim). But I'd rather move the
>>> getMimeType() implementation from PrintRenderer to PageableRenderer.
>>> That alone doesn't solve Rey's problem but get one step closer. I'll do
>>> that if you don't mind.
>> Sounds good, thanks.
>> BTW, I’ve just noticed that the javadoc of Renderer.getMimeType()
>> explicitly states that the returned value may be null.
>> Does it still apply today? Can we reasonably expect a renderer not to
>> return any mime type?
>>
>> Vincent
>>
>>
>>> On 03.04.2009 11:40:20 Vincent Hennebert wrote:
>>>> Hi,
>>>>
>>>>> Author: jeremias
>>>>> Date: Fri Apr 3 07:44:09 2009
>>>>> New Revision: 761554
>>>>>
>>>>> URL: http://svn.apache.org/viewvc?rev=761554&view=rev
>>>>> Log:
>>>>> Fixed a bug that left the PrintRenderer unconfigured even if a configuration was specified for "application/X-fop-print".
>>>>>
>>>> <snip/>
>>>>> + /** {@inheritDoc} */
>>>>> + public String getMimeType() {
>>>>> + return MimeConstants.MIME_FOP_PRINT;
>>>>> + }
>>>>> +
>>>> This method is defined in AbstractRenderer to return null. That makes me
>>>> wonder: is there a use case where you can expect a renderer to return
>>>> a null mime type?
>>>> The answer probably is no, in which case the definition of this method
>>>> should be removed from AbstractRenderer. That would force concrete
>>>> classes to implement a sensible getMimeType method and prevent this kind
>>>> of bug from occurring.
>>>> If I do it, the only class that no longer compiles is PageableRenderer.
>>>> Given that it is sub-classed by PrintRenderer and its constructor is not
>>>> called by external classes, I guess it can be made abstract.
>>>>
>>>> Is that ok if I apply such changes?
>>>> Thanks,
>>>> Vincent
>>>
>>>
>>>
>>> Jeremias Maerki
>
>
>
>
> Jeremias Maerki
>
Re: svn commit: r761554 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/print/PrintRenderer.java status.xml
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hi Vincent,
well, the "print" renderer doesn't really have an official MIME type.
The result could be paper, PDF, PostScript or whatever. I've given it a
pseudo MIME type "application/X-fop-print" just so configuration works
for this renderer, too. So it really depends how you look at it.
But I've just noticed that there's another renderer that really doesn't
have a MIME type: Java2DRenderer. So, if anyone subclassed
Java2DRenderer to paint pages in their own Swing application they are
going to find themselves with a compile error next time they upgrade.
Actually a reason to put the getMimeType() back in AbstractRenderer.
However, they have to implement getMimeType() anyway if they want to
configure the renderer through the XML configuration so probably no harm
done.
On 03.04.2009 12:31:32 Vincent Hennebert wrote:
> Hi Jeremias,
>
> Jeremias Maerki wrote:
> > Hi Vincent,
> >
> > Removing getMimeType() on AbstractRenderer is ok although that could
> > break someone else's renderer (risk very slim). But I'd rather move the
> > getMimeType() implementation from PrintRenderer to PageableRenderer.
> > That alone doesn't solve Rey's problem but get one step closer. I'll do
> > that if you don't mind.
>
> Sounds good, thanks.
> BTW, I’ve just noticed that the javadoc of Renderer.getMimeType()
> explicitly states that the returned value may be null.
> Does it still apply today? Can we reasonably expect a renderer not to
> return any mime type?
>
> Vincent
>
>
> > On 03.04.2009 11:40:20 Vincent Hennebert wrote:
> >> Hi,
> >>
> >>> Author: jeremias
> >>> Date: Fri Apr 3 07:44:09 2009
> >>> New Revision: 761554
> >>>
> >>> URL: http://svn.apache.org/viewvc?rev=761554&view=rev
> >>> Log:
> >>> Fixed a bug that left the PrintRenderer unconfigured even if a configuration was specified for "application/X-fop-print".
> >>>
> >> <snip/>
> >>> + /** {@inheritDoc} */
> >>> + public String getMimeType() {
> >>> + return MimeConstants.MIME_FOP_PRINT;
> >>> + }
> >>> +
> >> This method is defined in AbstractRenderer to return null. That makes me
> >> wonder: is there a use case where you can expect a renderer to return
> >> a null mime type?
> >> The answer probably is no, in which case the definition of this method
> >> should be removed from AbstractRenderer. That would force concrete
> >> classes to implement a sensible getMimeType method and prevent this kind
> >> of bug from occurring.
> >> If I do it, the only class that no longer compiles is PageableRenderer.
> >> Given that it is sub-classed by PrintRenderer and its constructor is not
> >> called by external classes, I guess it can be made abstract.
> >>
> >> Is that ok if I apply such changes?
> >> Thanks,
> >> Vincent
> >
> >
> >
> >
> > Jeremias Maerki
Jeremias Maerki
Re: svn commit: r761554 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/print/PrintRenderer.java
status.xml
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Jeremias,
Jeremias Maerki wrote:
> Hi Vincent,
>
> Removing getMimeType() on AbstractRenderer is ok although that could
> break someone else's renderer (risk very slim). But I'd rather move the
> getMimeType() implementation from PrintRenderer to PageableRenderer.
> That alone doesn't solve Rey's problem but get one step closer. I'll do
> that if you don't mind.
Sounds good, thanks.
BTW, I’ve just noticed that the javadoc of Renderer.getMimeType()
explicitly states that the returned value may be null.
Does it still apply today? Can we reasonably expect a renderer not to
return any mime type?
Vincent
> On 03.04.2009 11:40:20 Vincent Hennebert wrote:
>> Hi,
>>
>>> Author: jeremias
>>> Date: Fri Apr 3 07:44:09 2009
>>> New Revision: 761554
>>>
>>> URL: http://svn.apache.org/viewvc?rev=761554&view=rev
>>> Log:
>>> Fixed a bug that left the PrintRenderer unconfigured even if a configuration was specified for "application/X-fop-print".
>>>
>> <snip/>
>>> + /** {@inheritDoc} */
>>> + public String getMimeType() {
>>> + return MimeConstants.MIME_FOP_PRINT;
>>> + }
>>> +
>> This method is defined in AbstractRenderer to return null. That makes me
>> wonder: is there a use case where you can expect a renderer to return
>> a null mime type?
>> The answer probably is no, in which case the definition of this method
>> should be removed from AbstractRenderer. That would force concrete
>> classes to implement a sensible getMimeType method and prevent this kind
>> of bug from occurring.
>> If I do it, the only class that no longer compiles is PageableRenderer.
>> Given that it is sub-classed by PrintRenderer and its constructor is not
>> called by external classes, I guess it can be made abstract.
>>
>> Is that ok if I apply such changes?
>> Thanks,
>> Vincent
>
>
>
>
> Jeremias Maerki
Re: svn commit: r761554 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/print/PrintRenderer.java status.xml
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hi Vincent,
Removing getMimeType() on AbstractRenderer is ok although that could
break someone else's renderer (risk very slim). But I'd rather move the
getMimeType() implementation from PrintRenderer to PageableRenderer.
That alone doesn't solve Rey's problem but get one step closer. I'll do
that if you don't mind.
On 03.04.2009 11:40:20 Vincent Hennebert wrote:
> Hi,
>
> > Author: jeremias
> > Date: Fri Apr 3 07:44:09 2009
> > New Revision: 761554
> >
> > URL: http://svn.apache.org/viewvc?rev=761554&view=rev
> > Log:
> > Fixed a bug that left the PrintRenderer unconfigured even if a configuration was specified for "application/X-fop-print".
> >
> <snip/>
> > + /** {@inheritDoc} */
> > + public String getMimeType() {
> > + return MimeConstants.MIME_FOP_PRINT;
> > + }
> > +
>
> This method is defined in AbstractRenderer to return null. That makes me
> wonder: is there a use case where you can expect a renderer to return
> a null mime type?
> The answer probably is no, in which case the definition of this method
> should be removed from AbstractRenderer. That would force concrete
> classes to implement a sensible getMimeType method and prevent this kind
> of bug from occurring.
> If I do it, the only class that no longer compiles is PageableRenderer.
> Given that it is sub-classed by PrintRenderer and its constructor is not
> called by external classes, I guess it can be made abstract.
>
> Is that ok if I apply such changes?
> Thanks,
> Vincent
Jeremias Maerki
Re: svn commit: r761554 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/print/PrintRenderer.java
status.xml
Posted by Adrian Cumiskey <de...@cumiskey.com>.
Your suggestion sounds sensible enough to me (without having found time
to take a look at the code), +1.
Adrian.
Vincent Hennebert wrote:
> Hi,
>
>
>> Author: jeremias
>> Date: Fri Apr 3 07:44:09 2009
>> New Revision: 761554
>>
>> URL: http://svn.apache.org/viewvc?rev=761554&view=rev
>> Log:
>> Fixed a bug that left the PrintRenderer unconfigured even if a configuration was specified for "application/X-fop-print".
>>
>>
> <snip/>
>
>> + /** {@inheritDoc} */
>> + public String getMimeType() {
>> + return MimeConstants.MIME_FOP_PRINT;
>> + }
>> +
>>
>
> This method is defined in AbstractRenderer to return null. That makes me
> wonder: is there a use case where you can expect a renderer to return
> a null mime type?
> The answer probably is no, in which case the definition of this method
> should be removed from AbstractRenderer. That would force concrete
> classes to implement a sensible getMimeType method and prevent this kind
> of bug from occurring.
> If I do it, the only class that no longer compiles is PageableRenderer.
> Given that it is sub-classed by PrintRenderer and its constructor is not
> called by external classes, I guess it can be made abstract.
>
> Is that ok if I apply such changes?
> Thanks,
> Vincent
>
>
Re: svn commit: r761554 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/print/PrintRenderer.java
status.xml
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi,
> Author: jeremias
> Date: Fri Apr 3 07:44:09 2009
> New Revision: 761554
>
> URL: http://svn.apache.org/viewvc?rev=761554&view=rev
> Log:
> Fixed a bug that left the PrintRenderer unconfigured even if a configuration was specified for "application/X-fop-print".
>
<snip/>
> + /** {@inheritDoc} */
> + public String getMimeType() {
> + return MimeConstants.MIME_FOP_PRINT;
> + }
> +
This method is defined in AbstractRenderer to return null. That makes me
wonder: is there a use case where you can expect a renderer to return
a null mime type?
The answer probably is no, in which case the definition of this method
should be removed from AbstractRenderer. That would force concrete
classes to implement a sensible getMimeType method and prevent this kind
of bug from occurring.
If I do it, the only class that no longer compiles is PageableRenderer.
Given that it is sub-classed by PrintRenderer and its constructor is not
called by external classes, I guess it can be made abstract.
Is that ok if I apply such changes?
Thanks,
Vincent