Hi Dan,
Post by Dan AmelangHi Juan,
Â
Thanks for the screenshots, that helps a lot! Now, it would be ideal to
http://typekit.files.wordpress.com/2013/05/jensonw-900.png. But, I know
that you've got limited time to work on this, and such a thing wouldn't
be very high priority. Maybe down the road.
Â
Yes, that would be cool. Maybe I find some time to do it in the soon.
Post by Dan AmelangAlso, comparing your renderer+stroke font to the recently open sourced
Adobe font rasterizer would be interesting, too
(http://blog.typekit.com/2013/05/01/adobe-contributes-cff-rasterizer-to-freetype/).
As far as I can tell, Adobe's rasterizer is pretty much the the
state-of-the-art rasterizer for outline font rasterization. If you're
making the case that outline fonts are intrinsically unable to match the
quality of your stroke font, this comparison would be a convincing way to
do
Yes, the CFF hinter does a great job. The difference between the 3 samples
you is only in hinting. The three of them are drawn with whole pixel
coverage AA. Hinting outlines is really hard. And very specific to not
only to text but to a particular font specification: Hinting TTF and CFF
requires 2 different algorithms. Besides, it is slow (really slow). Because
of this, once drawn, the glyphs are usually cached for subsequent use. But
this means that you need to draw glyphs at integer pixel coordinates, so
you can reuse the cached rasterized glyphs.
All this goes against several of my objectives. I want that:
- Nothing is forced on a pixel grid. Any glyph can be drawn at any float
coordinates anytime, without performance penalty. This precludes the use of
a cache of rasterized glyphs.
- The same algorithm is used for graphics and text. I don't want complex
code that specific to TTF hinting.
So, for TTF, I do no hinting at all! My TTF samples look reasonably good
because (these are the focus of my defensive disclosure, and the heart of
my engine):
- I use something better than pixel coverage: prefiltering.
- I sample at the subpixel position, not at whole pixels.
So, I'm not claiming that my StrokeFont looks better than Adobe's CFF
sophisticated hinting. I say that my StrokeFonts look better than TTF
without any hinting at all, i.e. that my engine does a better job at
StrokeFonts than it can do at TTF; and better than, for example, Apple,
that doesn't do hinting either.
I believe that Adobe's CFF hinting, but rasterizing with prefiltering and
subpixel sampling (like I do) would give the best results of all. (if we
restrict to pixel grid for glyph position, and admit having comples, text
specific code).
Post by Dan AmelangGoing back to the topic of Morphic 3 rendering TrueType fonts, I'm
attaching a few unfiltered zooms from your M3-TTF.png (your more recent
M3-TTF-5.png looks the same in these areas). Notice the saturated colors
in the middle of the black text. You mentioned that you have color
fringing problems with <9 point sizes, but this font is about 12pt and
the problem doesn't look like color fringing (i.e., the coloring isn't
light nor just on the fringes, see
http://typekit.files.wordpress.com/2010/10/gdi-cleartype.png for what I
understand color fringing to look like). Maybe something else is going
on here?
Â
Yes. Those look like bugs, and I'll look into them. Those need to be fixed!
I'm attaching a sample of color fringes from M3-TTF.png, and the somewhate
better M3-TTF-5.png to show what I meant.
Post by Dan AmelangBack to your comments...I also like the idea of having a single
rasterizer for text and general graphics. At least one that can be just
parametrized or extended to handle text nicely as needed.
Yes, there is no question that one can improve on the visual output
of the popular rasterizers (cairo, skia, antigrain, qt, etc.). The
question has always been at what cost to software complexity and at what
cost to performance.
Â
Agreed. And I add to complexity and performace, the desire to draw glyphs
not only at integer pixel positions, as I said above.
Post by Dan AmelangI wasn't able to mentally separate your rasterization code from the rest
of the Morphic 3 code (I'm not a big Smalltalker, so maybe it's just
me), so I couldn't evaluate the complexity cost. It also looked like
there were several optimizations mixed in that could have thrown off my
understanding.
Â
It is not just you, you don't need to be polite! The engine is for a
Morphic UI, and handles the nested coordinate systems, possible clipping to
the owner's shape, and the identification of the morph at any pixel (to
dispatch Morphic events). Besides, it is an early stage, full of nearly
repeated code and experiments. It is even full of comments in Spanish that
were meant to be transient, and just for me! It is far from the mean code
quality of Cuis, for example.
To get faster to the relevant parts, try following this with the debugger:
(Morphic3Canvas onForm: Display) into: self runningWorld;
intoLocation: (MatrixTransform2x3 withRadians: 0 scale: 16 position:
***@182) negateYAxisAndAngle;
setupBorderWidth: 2 borderColor: Color red fillColor: nil strokeDashArray:
nil strokeDashArrayOffset: nil;
drawM3Box;
finishTrajectory;
setupBorderWidth: 16 borderColor: Color green fillColor: nil
strokeDashArray: nil strokeDashArrayOffset: nil;
initializeTrajectory;
drawM3Sans64;
finishTrajectory.
Display forceToScreen
The interesting methods are #addCurrentToTrajectory, that computes distance
to the edge for affected pixels (for any trajectory of the pen), and
#zMark1blendNoBackgroundAlphaAtX:y:pixelIndex:redIsInside:greenIsInside:blueIsInside:
that blends to the destination surface. The 2 senders to #zMark1... are for
drawing with and without fill.
Post by Dan AmelangWould you be interested in creating a clean, totally not optimized (and
thus slow), stand alone version of the rasterizer just for exposition
purposes? Something for people like me to learn from? Again, I know you
have very limited time. No rush.
Â
Yes, I could do that. The features provided would be just drawing some
shapes or glyphs, not unlike the snippet above, but trimmed of all
superfluous Morphic stuff and experiments. Just give me a few days and I'll
prepare it, in addition to fixing the "saturated color pixels" bug you
mentioned.
Cheers,
Juan Vuletich
Post by Dan AmelangDan
On Thu, Sep 18, 2014 at 6:38 AM, J. Vuletich (mail lists)
 Hi Dan,
Â
Post by Dan AmelangHi Juan,
Â
Glad that you're making progress! One question: how hard would it be to
use a TrueType font (or any fill-based font) with your rasterizer?
It is some work, as the TrueType font needs to be imported. I already
did this for DejaVu, printing a text sample to pdf, then converting
that to svg with Inkscape, and then loading the svg in Cuis / Morphic 3
and using a "CodeGeneratingCanvas" to write the Smalltalk code for me.
The attach is a sample image using just that font.
Post by Dan AmelangAnd, I would be interested in comparing the visual results of rendering
1) a TrueType font via FreeType, 2) a TrueType font via your Morphic 3
rasterizer, 3) your stroke font via the Morphic 3 rasterizer.
Taking a look at the attach, and the original attach in the mail linked
below, and comparing with FreeType samples (for example, the regular
a) For pointSize <=14
 1) Morphic 3 / StrokeFont with autohinting
 2) Feetype / TrueType with autohinting
 3) Morphic 3 / TrueType (no autohinting possible yet)
Note 1: For M3/TTF I could take the autohinting algorithm from
Freetype, and quality would be at least on par with it, for point sizes
Note 2: For point sizes < 9 (fills less than one pixel), M3/TTF
produces color fringes. I think this can be enhanced with some work.
I didn't spend much time on these issues, as I focused on StrokeFonts,
that give best results, at least for a programming environment.
Applications might need TTF, and there are possible enhancements to be done.
b) Rotated text. Here the difference in quality is rather small.
 1) Morphic 3 / StrokeFont (autohinting off)
 2) Feetype / TrueType
 3) Morphic 3 / TrueType
c) Point sizes > 14. Here I think the three alternatives look really
good, no autohinting is needed, and there is no clear winner. (Same
would go for most point sizes on a Retina or other hi dpi display, such
as phones.)
Post by Dan Amelang  I know option 3) produces the best quality, I'm just interested
in
Post by Dan AmelangPost by Dan Amelangthe visual details. Such a comparison might also be helpful to showcase
and explain your work to others.
It is also worth noting that the usual Cairo + Freetype (or Cairo +
Pango + Freetype) combo uses different algorithms for text and
graphics, as Freetype can do much better than Cairo, but can not do
general vector graphics. But Morphic 3 gives the same top quality for
vector graphics too, as text is done simply by calling the svg like
graphics primitives. Where Morphic 3 really stands out is when
comparing against Cairo for drawing vector graphics!
I hope this helps.
Cheers,
Juan Vuletich
Post by Dan AmelangDan
  On Wed, Sep 17, 2014 at 6:25 AM, J. Vuletich (mail lists)
Â
Post by J. Vuletich (mail lists)Hi Dan, Folks,
I finally published the Morphic 3 code in its current state. It is
still unfinished, and in need of cleanup. I hope you are still
interested in this stuff.
See
http://jvuletich.org/pipermail/cuis_jvuletich.org/2014-September/001692.html
Post by Dan AmelangPost by Dan AmelangPost by J. Vuletich (mail lists)I attached there a demo image with some SVG drawings, and some text at
rather small sizes, and some rotated text too. This took me a lot of
time,
because for maximum text quality I had to design a new font, based on pen
strokes (and not fills!). I based it on the technical lettering I learned
at high school.
I think I'm now close to the limit of what is possible on regular LCDs
when trying to optimize crispness, absence of pixellation and absence
of color fringes. What I need to do now is to fill in some details,
then optimization and a VM plugin. Then it could become the default
graphics engine for Cuis ( www.cuis-smalltalk.org[1][1] ).
Cheers,
Juan Vuletich
Â
Post by Dan AmelangHi Juan,
I think it's great that you are sharing your rasterization approach.
So far it sounds pretty interesting. FWIW, after you've released the
code, I would be interested in using this approach to create a higher
quality, drop-in replacement for the current "Rasterize" stage in the
Gezira rendering pipeline.
Best,
Dan
On Tue, Dec 3, 2013 at 6:24 PM, J. Vuletich (mail lists)
Â
Post by J. Vuletich (mail lists)Hi Folks,
The first defensive disclosure about Morphic 3 has been accepted and
published at
Â
http://www.defensivepublications.org/publications/prefiltering-antialiasing-for-general-vector-graphics
Post by Dan AmelangPost by Dan AmelangPost by J. Vuletich (mail lists)Post by Dan AmelangPost by J. Vuletich (mail lists)and http://ip.com/IPCOM/000232657 ..
Morphic 3 is described at
http://www.jvuletich.org/Morphic3/Morphic3-201006.html
This paves the way for releasing all the code, as no one will be able
to
patent it.
Cheers,
Juan Vuletich
_______________________________________________
fonc mailing list
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
http://vpri.org/mailman/listinfo/fonc
Â
Â
------
[1] http://www.cuis-smalltalk.org
Links:
------
[1] http://www.cuis-smalltalk.org
