xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject RE: Text rendering issues - again
Date Thu, 06 Nov 2008 10:40:50 GMT
Hi John,

"John C. Turnbull" <ozemale@ozemail.com.au> wrote on 11/05/2008 08:14:11 
PM:

> I have just stumbled upon something quite interesting...
[...] 
> 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!

   What a painful time to discover this.  I'm glad you have simpler
solution however.


> 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 
needchanging 
> > 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
>  [attachment "PGP.sig" deleted by Thomas E. DeWeese/449433/EKC] 
Mime
View raw message