xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John C. Turnbull" <ozem...@ozemail.com.au>
Subject RE: Text rendering issues - again
Date Thu, 06 Nov 2008 01:14:11 GMT
Hello again,

 

I have just stumbled upon something quite interesting...

 

As reported earlier, LCD or sub-pixel antialiasing only seems to work on
opaque surfaces, hence all the modifications to change the colour models to
not use alpha values.  Then it occurred to me, what would happen if I just
add an opaque rectangle behind the text that I want to render with LCD AA?
Well, it turns out that it works without any of the colour model changes!  I
guess it's smart enough to know that the surface is now opaque so it can
render with LCD AA.

 

So, after all that work, it seems that the only modifications that need to
be made to Batik to get LCD AA are to specify the appropriate rendering
hints in CSSUtilities#convertTextRendering() and also change the
declarations of the font render contexts at the top of BasicTextPainter to
be based on the appropriate rendering hints.  Then, just put an opaque
rectangle behind the text in the actual SVG and voila!

 

Cheers,

 

John

 

From: John C. Turnbull [mailto:ozemale@ozemail.com.au] 
Sent: Thursday, 6 November 2008 10:39
To: batik-users@xmlgraphics.apache.org
Subject: RE: Text rendering issues - again

 

* PGP Signed: 11/06/08 at 10:39:21

Hi Thomas,

 

I can report now that I have finally achieved LCD antialiased text so thanks
for your help.

 

The one caveat is that the SVG canvas always has a black background even if
I explicitly set it using svgCanvas.setBackground().  I guess this is
because every time a buffered image is created it defaults to a big black
void when no alpha values are used in the colour model.  I tried explicitly
filling the buffered images with a white rectangle but there seems to be a
number of places in the code where images are created and I don't want to
have to override every one of those classes.

 

So this means that if I want a white background on my special LCD canvas
then I need to do it in the SVG itself.  I can live with that.

 

Thanks again,

 

John

 

From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com] 
Sent: Tuesday, 4 November 2008 23:43
To: batik-users@xmlgraphics.apache.org
Cc: batik-users@xmlgraphics.apache.org
Subject: RE: Text rendering issues - again

 


Hi John,

"John C. Turnbull" <ozemale@ozemail.com.au> wrote on 11/04/2008 06:32:53 AM:

> BTW, what exactly is a "Rable" and a "Red" in the Batik context? 

   Rable -> Renderable  - abstract Image in float coordinate system 
   Red   -> Rendered    - concrete Image with pixels. 

>   
> John 
>   
> From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com] 
> Sent: Tuesday, 4 November 2008 22:04
> To: batik-users@xmlgraphics.apache.org
> Cc: batik-users@xmlgraphics.apache.org
> Subject: RE: Text rendering issues - again 
>   
> 
> Hi John,
> 
> "John C. Turnbull" <ozemale@ozemail.com.au> wrote on 11/04/2008 04:20:01
AM:
> 
> > My understanding is that I need to override methods in the renderer 
> > to create opaque buffered images instead of transparent ones.  The 
> > only way I can think of doing this is to change the colour model to 
> > one that does not store alpha values.  Well, that part is OK but in 
> > the repaint() method there is a point where the raster from the 
> > opaque buffered image I have created is copied into the CachableRed 
> > in rootCR.  This crashes complaining that the colour models are not 
> > compatible and it seems to be because the CachableRed has been 
> > created with a colour model that includes alpha whereas the buffered
> > image I have created does not. 
> 
>    Right unfortunately. 
> 
> > Am I approaching this the right way?  Does this mean that I also 
> > have to override the creation of the CachableRed in rootCR as well?
How? 
> 
>    It seems that is the case unfortunately.  The classes that need
changing 
> are batik.gvt.filter.GraphicsNodeRable8Bit and batik.gvt.filter.
> GraphicsNodeRed8Bit. 
> I think (hope) the changes are fairly simple.  The Rable only needs to be 
> modified to create your subclass of the Red (if you decide to create a new

> class instead of modifying Batik's).  In the Red8Bit replace or 
> augment the createColorModel method (alternately you might modify the
Batik 
> class so it can look for a rendering hint that it should be opaque). 
> 
> > From: John C. Turnbull [mailto:ozemale@ozemail.com.au] 
> > Sent: Tuesday, 4 November 2008 11:16
> > To: batik-users@xmlgraphics.apache.org
> > Subject: RE: Text rendering issues - again 
> >   
> > Hi Thomas, 
> >   
> > Thanks for the input. 
> >   
> > No, I never said anything about giving up!  I merely suggested that it
*may
> > * not be possible. 
> >   
> > So basically what you are suggesting is to create another renderer 
> > just for sub-pixel antialiased text rendering that creates an opaque
> > BufferedImage for the off-screen buffer and then have a special 
> > canvas type for using this renderer which overrides the appropriate 
> > methods.  Is this correct? 
> >   
> > That sounds quite do-able to me and would fit well into my usage 
> > pattern which is multiple canvasses.  I think the limitation of not 
> > being able to stack canvasses that include an LCD text-rendering 
> > canvas will also not be a problem. 
> >   
> > Cheers, 
> >   
> > John 
> >   
> > From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com] 
> > Sent: Tuesday, 4 November 2008 10:32
> > To: batik-users@xmlgraphics.apache.org
> > Cc: batik-users@xmlgraphics.apache.org
> > Subject: RE: Text rendering issues - again 
> >   
> > 
> > Hi John,
> > 
> > "John C. Turnbull" <ozemale@ozemail.com.au> wrote on 11/03/2008 05:08:58
PM:
> > 
> > > It seems that achieving LCD sub-pixel antialiasing with Batik may 
> > > not be possible. 
> > 
> >    Oh, come now, don't give up so easily ;) 
> > 
> > > An analysis of a trace log from the Batik code by Dmitri 
> > > Trembovetski of Sun has revealed that LCD antialiasing is not 
> > > happening because the image buffer in use is not opaque even though 
> > > I am explicitly setting the rendering hints to achieve it.  I guess 
> > > the reason for this is to enable SVG canvasses to be overlayed one 
> > > on top of the other and have the underlying graphics "show through" 
> > > the top layer. 
> > >   
> > > Does this sound correct?  I mean is this the reason why the image 
> > > buffer is not opaque?   
> > 
> >    Yes, this is why we use a transparent buffer.  Also it gives 
> > the 'correct' result for rendering something like a PNG where you 
> > want to preserve the transparency for later compositing. 
> > 
> > > Unfortunately LCD antialiasing only works on 
> > > opaque surfaces. 
> > 
> >    All rendering of the document is controlled by the 
> > batik.gvt.renderer.ImageRenderer used by the canvas.  We currently have 
> > two basic versions a static version (that uses a tile cache) and a 
> > dynamic one that just renders the requested region.  These classes 
> > create the BufferedImage that is actually rendered to by the canvas. 
> > 
> >    You can substitute your own ImageRenderer by replacing the 
> > 'createImageRenderer()' method on the canvas (probably by 
> > subclassing).  To create your own ImageRenderer, you might try 
> > simply replacing 'updateWorkingBuffers' with a version that 
> > constructs opaque BufferedImages.  Actually you will need to 
> > fix 'repaint' as well (it constructs a buffered image using the 
> > root GN's ColorModel which will have transparency). 
> > 
> > > As an aside, I can get LCD antialiasing to work if I render the 
> > > glyph vector into an opaque image and then blast that opaque image 
> > > on to the image buffer but this necessitates having a background 
> > > colour for the text which clears the rectangle in which the text is 
> > > bound.  Clearly this is not the solution. 
> > 
> >    Right, but if you make the canvas's Image opaque you simply 
> > lose the ability to 'stack' canvases. 
> > 
> > > Any thoughts? 
> > 
> >    See above... 
> > 
> > > From: John C. Turnbull [mailto:ozemale@ozemail.com.au] 
> > > Sent: Thursday, 30 October 2008 07:23
> > > To: batik-users@xmlgraphics.apache.org
> > > Subject: Text rendering issues - again 
> > >   
> > > I thought I had made the necessary modifications to achieve true 
> > > sub-pixel antialiasing in Batik but after consultation with Stuart 
> > > Pook I have found that this is not the case.  This is proving very 
> > > problematic. 
> > >   
> > > So, what would prevent Batik from rendering text using true sub-
> > > pixel antialiasing?  I have gone through the entire Batik code base 
> > > and changed everything that looked relevant but it still doesn't 
> > > work.  I have even gone to the extent of replacing the code in the 
> > > draw() method of AWTGVTGlyphVector where the text is actually 
> > > rendered with this: 
> > >   
> > > graphics2D.setColor(Color.BLACK); 
> > > graphics2D.setPaint(new Color(0, 0, 0)); 
> > > graphics2D.setTransform(new AffineTransform()); 
> > > graphics2D.setFont(new Font("Segoe UI", Font.PLAIN, 13)); 
> > > graphics2D.setRenderingHint(RenderingHints.KEY_ANTIALIASING, 
> > > RenderingHints.VALUE_ANTIALIAS_OFF); 
> > > graphics2D.setRenderingHint(RenderingHints.KEY_STROKE_CONTROL, 
> > > RenderingHints.VALUE_STROKE_PURE); 
> > > graphics2D.setRenderingHint(RenderingHints.KEY_RENDERING, 
> > > RenderingHints.VALUE_RENDER_QUALITY); 
> > > graphics2D.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING, 
> > >     RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB); 
> > > graphics2D.setRenderingHint(RenderingHints.KEY_TEXT_LCD_CONTRAST,
120); 
> > > graphics2D.setRenderingHint(RenderingHints.KEY_FRACTIONALMETRICS, 
> > >     RenderingHints.VALUE_FRACTIONALMETRICS_ON); 
> > > graphics2D.setRenderingHint(RenderingHints.KEY_ALPHA_INTERPOLATION, 
> > > RenderingHints.VALUE_ALPHA_INTERPOLATION_QUALITY); 
> > > graphics2D.setRenderingHint(RenderingHints.KEY_COLOR_RENDERING, 
> > > RenderingHints.VALUE_COLOR_RENDER_QUALITY); 
> > > graphics2D.setRenderingHint(RenderingHints.KEY_INTERPOLATION, 
> > > RenderingHints.VALUE_INTERPOLATION_BICUBIC); 
> > > graphics2D.drawString("Some test text", 20, 20); 
> > >   
> > > As you can see, I am setting every possible relevant rendering hint 
> > > to achieve sub-pixel antialiasing and this code fragment produces 
> > > the desired results when used outside of the Batik context.  But 
> > > within Batik, the text  is rendered using standard antialiasing only. 
> > >   
> > > It seems that something in either the graphics configuration or 
> > > component configuration within this Batik method is preventing true 
> > > sub-pixel antialiasing from happening even though I am explicitly 
> > > requesting it.  What could possibly be causing this? 
> > >   
> > > Thanks, 
> > >   
> > > -JCT

* John C. Turnbull <ozemale@ozemail.com.au>
* 0x8B577AC3

 


Mime
View raw message