Hi Thomas,
Thomas DeWeese wrote:
Hi Vladimir,......
Vladimir Bulatov wrote:
I'm not sure I fully understand what you mean by 'pass text strings directly to print driver'. This is Java we never talk to something as low level as a driver. We do talk to Java's implementation of Graphics2D for Print.
> _Most_ of our text is drawn using 'drawGlyphVector' in > cases where the text is stroked, or based on an SVG Font > we may draw shapes to the Graphics2D.
I understand this. In reality Graphics2D rasterises text, which it does bad in case of low resolution raster we have (20 dpi). However, if simple text output is used it may actually pass text directly to system (windows) to render it and system passes it to our printer driver. But this is not my main concern. My main concern is where to insert my special rendering code to be compatible with Batik architecture.
I assume by 'low resolution raster' you mean the font you have is a '20 dpi' raster font so a braille dot is just one pixel correct?
Have you tried constructing an SVGFont for Braille. It seems like it would be _really_ easy (even if you restricted yourself to the 'd' attribute and didn't use 'circle' elements as children of the Glyphs - which I would recommend - it wouldn't be that hard). This should solve the problem of the low resolution raster..
If you want to 'reimplement' text most of the work is done by the SVGTextElementBridge in the org.apache.batik.bridge package. However if all you want to do is extract the text from the document I wouldn't bother with Batik I would just use a little XSLT - so I imagine you want something more than just "text strings".
Just text extraction is not an option.
We are working on graphics, which represent information, like data
plots, maps, diagrams. So, actual rendering of the shapes is
important. I looked into SVGTextElementBridge already.
I traced down text rendering to intresting method:
org.apache.batik.bridge.BridgeContext.setTextPainter(TextPainter textPainter);
It looks like this is the place to change text renderer
implementation. But this method is not used anywhere in Batik and
I am wondering what was the initial intent to have this method.
So people could change the text rendering implementation :)
FOP does/did this so it could generate 'cleaner' text for PDF. You might want to look at what they did (http://xml.apache.org/fop) I think the code of interest would be in the org.apache.fop.pdf package.
That all said my initial response on how to modify output for braille would be to use something like a user style sheet, with an '@media braille' rule. The Batik browser allows you to set the CSS Media in use for display.
Can you explain a little more. What happens if I will use '@media braille' in CSS? Will rendering be done by something else. How I implement rendering for that rule? Is it possible to use different rules for printing and for monitor?
So a user stylesheet like:
@media braille { text { font-family: SVGBraille !important; font-size: 30 !important }
tspan { font-family: SVGBraille !important; font-size: 30 !important }
tref { font-family: SVGBraille !important; font-size: 30 !important }
}Would pretty much ensure that all text was drawn with the SVGBraille font at a size of 30 (in the local coordinate system - which may not always be what you want) when the document is displayed on a 'braille' "media". In the Squiggle preferences you can set what the output media type is and provide a user style sheet. Similarly the svgrasterizer allows you to specify the media and user style sheet to use.
Vladimir
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
