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
