Hi Rob,
Rob Davis-5 <[email protected]> wrote on 12/09/2008 05:56:33 AM:
> Is it because:
> - People are too busy
One vote!
> Rob Davis-5 wrote:
> >
> > Is it possible for the batik PNG/bitmap rasteriser to inform the
> > user/calling code if it encounters a line that is subpixel in width
and so
> > would not render - i.e. not appear? That is, will be omitted, missed
out
> > in the resultant PNG image because it is too thin?
> >
> > Does this feature already exist?
No.
> > Perhaps some kind of Exception could be raised or interface/call back
> > method?
> >
> > Could you outline what would be required to extend the batik classes
that
> > are involved in this?
There are two cases to consider. The first is the fairly easy one
which is where the 'line' is drawn as the stroke on an object. Knowing
that the line in this case will be <1 pixel is simply a matter of
multiplying the stroke width by the square root of the determinate of
the user-space to device-space affine transform (the drawing transform
for the line). This could probably be added to
batik.gvt.StrokeShapePainter
in it's paint method.
The second case is where part of a piece of a path is small/narrow
enough that it will render as <1 pixel wide/high. This would be
very difficult to detect. The easiest way (which is like saying
the easiest way to clime Mt. Everest) would be to write a new rasterizer
that looked for this sort of case.
> > I'm particularly interested in two-tone - i.e. black and white only,
no
> > gray/grey shades/levels. This means there would be no anti-aliasing.
> >
> > I'm guessing that the anti-aliasing engine in batik is used to give
very
> > thin lines lighter shades of grey - so the fact that it knows enough
to do
> > this, perhaps this part of the code could be used to raise an
exception
> > with the knowledge that anti-aliasing is not wanted.
We use the Java 2D rasterizer, so we don't really know what it's
doing.
And in anycase if you are rendering with anti-aliasing on there are always
anti-aliased pixels and it doesn't really indicate a problem (for example
at
the tips of characters).
> > This thread relates to my previous discussion about Chinese characters
and
> > minimal dpi rendering for them in a monochrome bi-level 2 color only
> > environment. A good solution was offered by using a very complex
Chinese
> > character as a benchmark. See:
> >
> > http://www.nabble.com/Chinese-characters---what%27s-the-smallest-
> recpmmended-dpi-resolution-rendering-to17425380.html#a17503472
> >
> > However, what about a more general solution that could cope with any
> > scenario of thin lines and detect if they would be missing from the
> > resultant bitmap output?
So unfortunately characters fall into the second case above.
I am not aware of any algorithm that can do this. You might be
able to do something with machine vision algorithms to construct a
'stroked' version of the glyph (rendered at a higher resolution)
and then try to match that against your low res version. But that
would be a significant research project....
> > Perhaps even a solution could suggest a minimum dpi for the SVG for
all
> > lines to be visible in a 2 colour, 1 bit per pixel bitmap?
See above...
