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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, 4 November 2008 23:43 To: [email protected] Cc: [email protected] Subject: RE: Text rendering issues - again Hi John, "John C. Turnbull" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, 4 November 2008 22:04 > To: [email protected] > Cc: [email protected] > Subject: RE: Text rendering issues - again > > > Hi John, > > "John C. Turnbull" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > Sent: Tuesday, 4 November 2008 11:16 > > To: [email protected] > > 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: [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
PGP.sig
Description: PGP signature
