You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Patrick Jaromin <pa...@jgsullivan.com> on 2008/01/07 14:36:00 UTC
RE: Custom Fonts in Java2DRenderer & Hardcoded ColorModel
Jeremias-
I mailed the ICLA a month ago today...just wanted to make sure it was
received and cleared admin.
- Patrick
Patrick K. Jaromin
VP Technology
312.943.1600 * fax 312.640.8100
JGSullivan Interactive, Inc.
http://JGSullivan.com
-----Original Message-----
From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
Sent: Friday, December 07, 2007 5:03 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Custom Fonts in Java2DRenderer & Hardcoded ColorModel
There were a couple of small problems to fix in the PCLRenderer but it
seems to work fine now, even with custom fonts. So from my POV the patch
is ready to be applied. I'll just have to wait for the ICLA.
On 07.12.2007 11:41:07 Jeremias Maerki wrote:
> Patrick,
>
> sorry for the delay. I've taken a first look at your patch. Looks
good.
> The only thing I have changed is moving FontMetricMapper back to
> render.java2d since no other class in the fonts package deals with AWT
> fonts, yet. And FontMetricMapper would have been the first.
>
> Since your patch contains new files, would you please fill out and
> submit an ICLA to the Apache Software Foundation? You can find the
> form
> here: http://www.apache.org/licenses/#clas
> Please also check if your company might need to submit a CCLA, too.
> As soon as I've received notification from the ASF's secretary, I'll
> commit your patch.
>
> In the meantime, I'll do some more testing.
>
> More inline below...
>
> On 02.12.2007 22:45:13 Patrick Jaromin wrote:
> > Jeremias-
> >
> > Alright. Between the kid's naps, I've managed to create a patch to
> > allow for user-configured fonts in Java2DRenderers. I've tested it
> > with the PNG and TIFF renderers.
> >
> > A couple things...
> >
> > 1) I've renamed the original "FontMetricMapper" to
> > "SystemFontMetricMapper" and created a new interface
> > "org.apache.fop.fonts.FontMetricMapper". Then the new implementation
> > is called "CustomFontMetricMapper," which represents the fonts *not*
> > installed on the system but described in the fop config. I looked at
> > maintaining the original naming but just didn't like any of the
> > names I could think of. If this won't fly perhaps someone can
> > suggest an alternative naming strategy.
>
> It's fine IMO.
>
> > 2) I changed the signature of the FontInfo.setup method (the java2d
> > version of that class). It actually now more closely resembles its
> > counterpart. Since the PCLRenderer uses this same class I changed
> > the call there as well. However, I don't know how to test that
> > renderer properly and am just guessing that it would be fine. If
> > not, it would be simple to overload the setup method with the former
> > signature and revert PCLRenderer.
>
> I'll do the testing there.
>
> > 3) I don't really know how to write tests for these changes and so,
> > consequently, I didn't. I used the fop script to output PNG and TIFF
> > images with various combinations of settings in my userconfig.xml
> > and it ultimately worked as expected. I'm a pretty big proponent of
> > test-driven development but it wasn't obvious to me how to add new
> > tests -- I'm not familiar with what's setup here and don't have a
> > ton of free time to research it. Let me know if there's something I
> > could read that would help me resolve that quickly.
>
> I know, renderer testing is tricky to do in a way that testing is
> stable and useful. Therefore we don't do that, yet. We used to have
> binary comparison for PDF files but that too unstable and people
didn't use it.
> For PDF, PS and Java2D (and related) I can create bitmaps which I can
> compare visually by hand. For the other formats, this is much more
> tedious. There just isn't a one solution that fits all cases.
>
> > 4) A minor thing...I had originally implemented
> > "CustomFontMetricsMapper.mapChar()" method to simply return the
> > character provided (as the original FontMetricsMapper did). However,
> > there is a side-effect in the underlying Typeface implementation
> > delegate - MultiByteFont - of calling it's mapChar() method. If you
> > *don'* call it, then "embeded fonts" (which these are considered
> > since they pass the test (MultiBytFont.isEmbedable()) ) won't
> > work...NPE on getWidth(). I didn't spend much time looking for a
> > solution to this -- I simply delegated the mapChar method to the
> > internal typeface, which solved the problem. I don't think this is
> > wrong, just don't like to leave these side-effect. I could see
> > somehow re-working the definition of "embeded font" and come up with
> > some way to make it so that these fonts aren't classed
> > "embeded"...though it's probably far more trouble than it's
worth...but thought I'd mention it.
>
> I'll look into it.
>
> > I've attached the patch to this message...I apologize if this is
> > problematic but I wanted to check primarily on the FontMetricMapper
> > rename before doing anything else with it, like sumbmitting to
Bugzilla.
>
> Not strictly necessary now that I've already patched a local working
> copy of FOP. Generally, it is a good idea, though. A patch is less
> likely to be forgotten though that still occasionally happens. :-(
>
> > Let me know.
> >
> > Thanks!
> >
> > - Patrick
> <snip/>
>
>
>
> Jeremias Maerki
>
Jeremias Maerki
RE: Custom Fonts in Java2DRenderer & Hardcoded ColorModel
Posted by Patrick Jaromin <pa...@jgsullivan.com>.
Jeremias-
I'll watch for the merge so I can look at upgrading my project HEAD to
FOP HEAD.
Thanks!
- Patrick
Patrick K. Jaromin
VP Technology
312.943.1600 * fax 312.640.8100
JGSullivan Interactive, Inc.
http://JGSullivan.com
-----Original Message-----
From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
Sent: Monday, January 07, 2008 9:13 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Custom Fonts in Java2DRenderer & Hardcoded ColorModel
Patrick,
thanks for pinging me about this. I've just committed the patch. See:
http://issues.apache.org/bugzilla/show_bug.cgi?id=44176
Please also review the color model issue when I can merge the image
package redesign branch into Trunk later this week.
On 07.01.2008 14:36:00 Patrick Jaromin wrote:
> Jeremias-
>
> I mailed the ICLA a month ago today...just wanted to make sure it was
> received and cleared admin.
>
> - Patrick
>
>
> Patrick K. Jaromin
> VP Technology
> 312.943.1600 * fax 312.640.8100
>
> JGSullivan Interactive, Inc.
> http://JGSullivan.com
>
> -----Original Message-----
> From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
> Sent: Friday, December 07, 2007 5:03 AM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: Custom Fonts in Java2DRenderer & Hardcoded ColorModel
>
> There were a couple of small problems to fix in the PCLRenderer but it
> seems to work fine now, even with custom fonts. So from my POV the
> patch is ready to be applied. I'll just have to wait for the ICLA.
>
> On 07.12.2007 11:41:07 Jeremias Maerki wrote:
> > Patrick,
> >
> > sorry for the delay. I've taken a first look at your patch. Looks
> good.
> > The only thing I have changed is moving FontMetricMapper back to
> > render.java2d since no other class in the fonts package deals with
> > AWT
>
> > fonts, yet. And FontMetricMapper would have been the first.
> >
> > Since your patch contains new files, would you please fill out and
> > submit an ICLA to the Apache Software Foundation? You can find the
> > form
> > here: http://www.apache.org/licenses/#clas
> > Please also check if your company might need to submit a CCLA, too.
> > As soon as I've received notification from the ASF's secretary, I'll
> > commit your patch.
> >
> > In the meantime, I'll do some more testing.
> >
> > More inline below...
> >
> > On 02.12.2007 22:45:13 Patrick Jaromin wrote:
> > > Jeremias-
> > >
> > > Alright. Between the kid's naps, I've managed to create a patch to
> > > allow for user-configured fonts in Java2DRenderers. I've tested it
> > > with the PNG and TIFF renderers.
> > >
> > > A couple things...
> > >
> > > 1) I've renamed the original "FontMetricMapper" to
> > > "SystemFontMetricMapper" and created a new interface
> > > "org.apache.fop.fonts.FontMetricMapper". Then the new
> > > implementation
>
> > > is called "CustomFontMetricMapper," which represents the fonts
> > > *not*
>
> > > installed on the system but described in the fop config. I looked
> > > at
>
> > > maintaining the original naming but just didn't like any of the
> > > names I could think of. If this won't fly perhaps someone can
> > > suggest an alternative naming strategy.
> >
> > It's fine IMO.
> >
> > > 2) I changed the signature of the FontInfo.setup method (the
> > > java2d version of that class). It actually now more closely
> > > resembles its counterpart. Since the PCLRenderer uses this same
> > > class I changed the call there as well. However, I don't know how
> > > to test that renderer properly and am just guessing that it would
> > > be fine. If not, it would be simple to overload the setup method
> > > with the former
>
> > > signature and revert PCLRenderer.
> >
> > I'll do the testing there.
> >
> > > 3) I don't really know how to write tests for these changes and
> > > so, consequently, I didn't. I used the fop script to output PNG
> > > and TIFF
>
> > > images with various combinations of settings in my userconfig.xml
> > > and it ultimately worked as expected. I'm a pretty big proponent
> > > of test-driven development but it wasn't obvious to me how to add
> > > new tests -- I'm not familiar with what's setup here and don't
> > > have a ton of free time to research it. Let me know if there's
> > > something I could read that would help me resolve that quickly.
> >
> > I know, renderer testing is tricky to do in a way that testing is
> > stable and useful. Therefore we don't do that, yet. We used to have
> > binary comparison for PDF files but that too unstable and people
> didn't use it.
> > For PDF, PS and Java2D (and related) I can create bitmaps which I
> > can compare visually by hand. For the other formats, this is much
> > more tedious. There just isn't a one solution that fits all cases.
> >
> > > 4) A minor thing...I had originally implemented
> > > "CustomFontMetricsMapper.mapChar()" method to simply return the
> > > character provided (as the original FontMetricsMapper did).
> > > However,
>
> > > there is a side-effect in the underlying Typeface implementation
> > > delegate - MultiByteFont - of calling it's mapChar() method. If
> > > you
> > > *don'* call it, then "embeded fonts" (which these are considered
> > > since they pass the test (MultiBytFont.isEmbedable()) ) won't
> > > work...NPE on getWidth(). I didn't spend much time looking for a
> > > solution to this -- I simply delegated the mapChar method to the
> > > internal typeface, which solved the problem. I don't think this is
> > > wrong, just don't like to leave these side-effect. I could see
> > > somehow re-working the definition of "embeded font" and come up
> > > with
>
> > > some way to make it so that these fonts aren't classed
> > > "embeded"...though it's probably far more trouble than it's
> worth...but thought I'd mention it.
> >
> > I'll look into it.
> >
> > > I've attached the patch to this message...I apologize if this is
> > > problematic but I wanted to check primarily on the
> > > FontMetricMapper rename before doing anything else with it, like
> > > sumbmitting to
> Bugzilla.
> >
> > Not strictly necessary now that I've already patched a local working
> > copy of FOP. Generally, it is a good idea, though. A patch is less
> > likely to be forgotten though that still occasionally happens. :-(
> >
> > > Let me know.
> > >
> > > Thanks!
> > >
> > > - Patrick
> > <snip/>
> >
> >
> >
> > Jeremias Maerki
> >
>
>
>
>
> Jeremias Maerki
>
>
>
Jeremias Maerki
Re: Custom Fonts in Java2DRenderer & Hardcoded ColorModel
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Patrick,
thanks for pinging me about this. I've just committed the patch. See:
http://issues.apache.org/bugzilla/show_bug.cgi?id=44176
Please also review the color model issue when I can merge the image
package redesign branch into Trunk later this week.
On 07.01.2008 14:36:00 Patrick Jaromin wrote:
> Jeremias-
>
> I mailed the ICLA a month ago today...just wanted to make sure it was
> received and cleared admin.
>
> - Patrick
>
>
> Patrick K. Jaromin
> VP Technology
> 312.943.1600 * fax 312.640.8100
>
> JGSullivan Interactive, Inc.
> http://JGSullivan.com
>
> -----Original Message-----
> From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
> Sent: Friday, December 07, 2007 5:03 AM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: Custom Fonts in Java2DRenderer & Hardcoded ColorModel
>
> There were a couple of small problems to fix in the PCLRenderer but it
> seems to work fine now, even with custom fonts. So from my POV the patch
> is ready to be applied. I'll just have to wait for the ICLA.
>
> On 07.12.2007 11:41:07 Jeremias Maerki wrote:
> > Patrick,
> >
> > sorry for the delay. I've taken a first look at your patch. Looks
> good.
> > The only thing I have changed is moving FontMetricMapper back to
> > render.java2d since no other class in the fonts package deals with AWT
>
> > fonts, yet. And FontMetricMapper would have been the first.
> >
> > Since your patch contains new files, would you please fill out and
> > submit an ICLA to the Apache Software Foundation? You can find the
> > form
> > here: http://www.apache.org/licenses/#clas
> > Please also check if your company might need to submit a CCLA, too.
> > As soon as I've received notification from the ASF's secretary, I'll
> > commit your patch.
> >
> > In the meantime, I'll do some more testing.
> >
> > More inline below...
> >
> > On 02.12.2007 22:45:13 Patrick Jaromin wrote:
> > > Jeremias-
> > >
> > > Alright. Between the kid's naps, I've managed to create a patch to
> > > allow for user-configured fonts in Java2DRenderers. I've tested it
> > > with the PNG and TIFF renderers.
> > >
> > > A couple things...
> > >
> > > 1) I've renamed the original "FontMetricMapper" to
> > > "SystemFontMetricMapper" and created a new interface
> > > "org.apache.fop.fonts.FontMetricMapper". Then the new implementation
>
> > > is called "CustomFontMetricMapper," which represents the fonts *not*
>
> > > installed on the system but described in the fop config. I looked at
>
> > > maintaining the original naming but just didn't like any of the
> > > names I could think of. If this won't fly perhaps someone can
> > > suggest an alternative naming strategy.
> >
> > It's fine IMO.
> >
> > > 2) I changed the signature of the FontInfo.setup method (the java2d
> > > version of that class). It actually now more closely resembles its
> > > counterpart. Since the PCLRenderer uses this same class I changed
> > > the call there as well. However, I don't know how to test that
> > > renderer properly and am just guessing that it would be fine. If
> > > not, it would be simple to overload the setup method with the former
>
> > > signature and revert PCLRenderer.
> >
> > I'll do the testing there.
> >
> > > 3) I don't really know how to write tests for these changes and so,
> > > consequently, I didn't. I used the fop script to output PNG and TIFF
>
> > > images with various combinations of settings in my userconfig.xml
> > > and it ultimately worked as expected. I'm a pretty big proponent of
> > > test-driven development but it wasn't obvious to me how to add new
> > > tests -- I'm not familiar with what's setup here and don't have a
> > > ton of free time to research it. Let me know if there's something I
> > > could read that would help me resolve that quickly.
> >
> > I know, renderer testing is tricky to do in a way that testing is
> > stable and useful. Therefore we don't do that, yet. We used to have
> > binary comparison for PDF files but that too unstable and people
> didn't use it.
> > For PDF, PS and Java2D (and related) I can create bitmaps which I can
> > compare visually by hand. For the other formats, this is much more
> > tedious. There just isn't a one solution that fits all cases.
> >
> > > 4) A minor thing...I had originally implemented
> > > "CustomFontMetricsMapper.mapChar()" method to simply return the
> > > character provided (as the original FontMetricsMapper did). However,
>
> > > there is a side-effect in the underlying Typeface implementation
> > > delegate - MultiByteFont - of calling it's mapChar() method. If you
> > > *don'* call it, then "embeded fonts" (which these are considered
> > > since they pass the test (MultiBytFont.isEmbedable()) ) won't
> > > work...NPE on getWidth(). I didn't spend much time looking for a
> > > solution to this -- I simply delegated the mapChar method to the
> > > internal typeface, which solved the problem. I don't think this is
> > > wrong, just don't like to leave these side-effect. I could see
> > > somehow re-working the definition of "embeded font" and come up with
>
> > > some way to make it so that these fonts aren't classed
> > > "embeded"...though it's probably far more trouble than it's
> worth...but thought I'd mention it.
> >
> > I'll look into it.
> >
> > > I've attached the patch to this message...I apologize if this is
> > > problematic but I wanted to check primarily on the FontMetricMapper
> > > rename before doing anything else with it, like sumbmitting to
> Bugzilla.
> >
> > Not strictly necessary now that I've already patched a local working
> > copy of FOP. Generally, it is a good idea, though. A patch is less
> > likely to be forgotten though that still occasionally happens. :-(
> >
> > > Let me know.
> > >
> > > Thanks!
> > >
> > > - Patrick
> > <snip/>
> >
> >
> >
> > Jeremias Maerki
> >
>
>
>
>
> Jeremias Maerki
>
>
>
Jeremias Maerki