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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 4 November 2008 10:32
To: [email protected]
Cc: [email protected]
Subject: RE: Text rendering issues - again

 


Hi John,

"John C. Turnbull" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] 
> Sent: Thursday, 30 October 2008 07:23
> To: [email protected]
> 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

Reply via email to