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 Tue, 04 Nov 2008 11:32:53 GMT
Hi Thomas,

 

OK, thanks again for the info.

 

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

 

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


Mime
View raw message