Re: [fonc] Morphic 3 defensive disclosure

2014-09-24 Thread J. Vuletich (mail lists)

 Hi Shawn,

I'm not intending to patent it. But I want to avoid others to patent it and
restrict my right (and yours) to use it. Feel free to use it as you please.
The code is MIT license, as is Cuis Smalltalk. In any case, I'd appreciate
reasonable and fair attribution of the ideas in stuff you, or anybody else,
publishes.

Cheers,
Juan Vuletich

Quoting shawnmorel :


Agreed. these are impressive!
   
  I was curious about the defensive disclosure. Are you intending to
patent this work or simply preventing a non-open source implementation
from claiming patent infringements? I’d be curious to try and recreate
some of these results :)
   
  shawn

   On Sep 24, 2014, at 5:24 PM, Dan Amelang
 wrote:


Hi Juan,
 
Yes, that is some of the best TTF non-hinted rendering I've seen. Nice
work!

And, yes, it does look like the bug is gone, thanks!
 
It will be interesting to look through a simplified, stand-alone(ish)
version of the code to fully grasp the detail of your approach. Again,
no rush, though.

Dan


  On Tue, Sep 23, 2014 at 6:50 PM, J. Vuletich (mail lists)
 wrote:


Hi Dan,

Quoting Dan Amelang :


Hi Juan,
 
Thanks for the screenshots, that helps a lot! Now, it would be ideal
to have a visual like this to for the comparison:
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.



Please take a look


at https://dl.dropboxusercontent.com/u/13285702/Morphic3-TimesNewRomanSample.png

I used Times New Roman for the sample. It is similar but not identical
to the font in the Adobe demo image. I did it by converting the text
to SVG in Inkscape, then using Morphic 3 to draw the svg file.

There is no hinting at all here! Just better rasterization. The shape
and weight is truer and more uniform (especially at smaller sizes),
most glyphs look sharper. Starting from the third line, the quality is
consistently better.
 


Also, 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

so.



I think the real contribution of Morphic 3 here is better
rasterization, that doesn't need hinting to give very crisp and
detailed results.
 


Going 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?
 
... snip ...

    
Dan



Yes. There was a bug there. It only happened for curve segments
shorter than one pixel, affecting only very small point sizes. Thanks
for pointing it out! The sample I prepared today clearly shows that
the bug was fixed.

Cheers,
Juan Vuletich


___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc


Re: [fonc] Morphic 3 defensive disclosure

2014-09-24 Thread shawnmorel
Agreed. these are impressive!

I was curious about the defensive disclosure. Are you intending to patent this 
work or simply preventing a non-open source implementation from claiming patent 
infringements? I’d be curious to try and recreate some of these results :)

shawn

On Sep 24, 2014, at 5:24 PM, Dan Amelang  wrote:

> Hi Juan,
> 
> Yes, that is some of the best TTF non-hinted rendering I've seen. Nice work!
> 
> And, yes, it does look like the bug is gone, thanks!
> 
> It will be interesting to look through a simplified, stand-alone(ish) version 
> of the code to fully grasp the detail of your approach. Again, no rush, 
> though.
> 
> Dan
> 
> On Tue, Sep 23, 2014 at 6:50 PM, J. Vuletich (mail lists) 
>  wrote:
> Hi Dan,
> 
> Quoting Dan Amelang :
> 
>> Hi Juan,
>>  
>> Thanks for the screenshots, that helps a lot! Now, it would be ideal to have 
>> a visual like this to for the comparison: 
>> 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.
> 
> Please take a look at 
> https://dl.dropboxusercontent.com/u/13285702/Morphic3-TimesNewRomanSample.png
> I used Times New Roman for the sample. It is similar but not identical to the 
> font in the Adobe demo image. I did it by converting the text to SVG in 
> Inkscape, then using Morphic 3 to draw the svg file.
> 
> There is no hinting at all here! Just better rasterization. The shape and 
> weight is truer and more uniform (especially at smaller sizes), most glyphs 
> look sharper. Starting from the third line, the quality is consistently 
> better.
> 
> 
>> Also, 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 so.
> 
> 
> I think the real contribution of Morphic 3 here is better rasterization, that 
> doesn't need hinting to give very crisp and detailed results.
> 
> 
>> Going 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?
>>  
>> ... snip ...
>>  
>> Dan
> 
> Yes. There was a bug there. It only happened for curve segments shorter than 
> one pixel, affecting only very small point sizes. Thanks for pointing it out! 
> The sample I prepared today clearly shows that the bug was fixed.
> 
> Cheers,
> Juan Vuletich
> 
> 
> ___
> fonc mailing list
> [email protected]
> http://vpri.org/mailman/listinfo/fonc

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc


Re: [fonc] Morphic 3 defensive disclosure

2014-09-24 Thread Dan Amelang
Hi Juan,

Yes, that is some of the best TTF non-hinted rendering I've seen. Nice work!

And, yes, it does look like the bug is gone, thanks!

It will be interesting to look through a simplified, stand-alone(ish)
version of the code to fully grasp the detail of your approach. Again, no
rush, though.

Dan

On Tue, Sep 23, 2014 at 6:50 PM, J. Vuletich (mail lists) <
[email protected]> wrote:

>  Hi Dan,
>
> Quoting Dan Amelang :
>
>   Hi Juan,
>
> Thanks for the screenshots, that helps a lot! Now, it would be ideal to
> have a visual like this to for the comparison:
> 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.
>
>
> Please take a look at
> https://dl.dropboxusercontent.com/u/13285702/Morphic3-TimesNewRomanSample.png
> I used Times New Roman for the sample. It is similar but not identical to
> the font in the Adobe demo image. I did it by converting the text to SVG in
> Inkscape, then using Morphic 3 to draw the svg file.
>
> There is no hinting at all here! Just better rasterization. The shape and
> weight is truer and more uniform (especially at smaller sizes), most glyphs
> look sharper. Starting from the third line, the quality is consistently
> better.
>
>   Also, 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 so.
>
>
> I think the real contribution of Morphic 3 here is better rasterization,
> that doesn't need hinting to give very crisp and detailed results.
>
>   Going 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?
>
> ... snip ...
>
> Dan
>
>
> Yes. There was a bug there. It only happened for curve segments shorter
> than one pixel, affecting only very small point sizes. Thanks for pointing
> it out! The sample I prepared today clearly shows that the bug was fixed.
>
> Cheers,
> Juan Vuletich
>
___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc


Re: [fonc] Morphic 3 defensive disclosure

2014-09-23 Thread J. Vuletich (mail lists)

 Hi Dan,

Quoting Dan Amelang :


Hi Juan,
 
Thanks for the screenshots, that helps a lot! Now, it would be ideal to
have a visual like this to for the comparison:
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.


Please take a look
at https://dl.dropboxusercontent.com/u/13285702/Morphic3-TimesNewRomanSample.png
I used Times New Roman for the sample. It is similar but not identical to
the font in the Adobe demo image. I did it by converting the text to SVG in
Inkscape, then using Morphic 3 to draw the svg file.

There is no hinting at all here! Just better rasterization. The shape and
weight is truer and more uniform (especially at smaller sizes), most glyphs
look sharper. Starting from the third line, the quality is consistently
better.


Also, 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

so.


I think the real contribution of Morphic 3 here is better rasterization,
that doesn't need hinting to give very crisp and detailed results.


Going 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?
 
... snip ...

    
Dan


Yes. There was a bug there. It only happened for curve segments shorter
than one pixel, affecting only very small point sizes. Thanks for pointing
it out! The sample I prepared today clearly shows that the bug was fixed.

Cheers,
Juan Vuletich
___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc


Re: [fonc] Morphic 3 defensive disclosure

2014-09-19 Thread J. Vuletich (mail lists)

 Hi Shawn,

Quoting shawnmorel :


- I use something better than pixel coverage: pre filtering.


    
   I’m actually really curious about this. Is there a version of this
paper that you own copyrights to that you could point us to?
   http://ip.com/IPCOM/000232657


You can download it freely
from 
http://www.defensivepublications.org/publications/prefiltering-antialiasing-for-general-vector-graphics
​

Would 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.


  I’d also add that for a newcomer, it might even help your
rasterization ideas spread more. Much of the discussion
here http://www.jvuletich.org/Morphic3/Morphic3-201006.html starts with
a discussion about improving on morphic, priming me to think about GUI
toolkits and problems that arise there. Much of the meat of the content
is about the rasterization ideas, which in my mind are quite different.
e.g. you could build many things on the new rasterizer and you could
build a new guy toolkit on many different rasterizers :)
   


Sure.​ Thanks for the feedback!


shawn
   
   
   


Cheers,
Juan Vuletich
___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc


Re: [fonc] Morphic 3 defensive disclosure

2014-09-19 Thread shawnmorel
> - I use something better than pixel coverage: pre filtering.
> 

I’m actually really curious about this. Is there a version of this paper that 
you own copyrights to that you could point us to?
http://ip.com/IPCOM/000232657

>> Would 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.
> 

I’d also add that for a newcomer, it might even help your rasterization ideas 
spread more. Much of the discussion here 
http://www.jvuletich.org/Morphic3/Morphic3-201006.html starts with a discussion 
about improving on morphic, priming me to think about GUI toolkits and problems 
that arise there. Much of the meat of the content is about the rasterization 
ideas, which in my mind are quite different. e.g. you could build many things 
on the new rasterizer and you could build a new guy toolkit on many different 
rasterizers :)

shawn



___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc


Re: [fonc] Morphic 3 defensive disclosure

2014-09-19 Thread J. Vuletich (mail lists)

 Hi Dan,

Quoting Dan Amelang :


Hi Juan,
 
Thanks for the screenshots, that helps a lot! Now, it would be ideal to
have a visual like this to for the comparison:
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.


Also, 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

so.
 


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).


Going 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.


Back 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.


I 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

Re: [fonc] Morphic 3 defensive disclosure

2014-09-18 Thread Dan Amelang
Hi Juan,

Thanks for the screenshots, that helps a lot! Now, it would be ideal to
have a visual like this to for the comparison:
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.

Also, 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 so.

Going 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?

Back 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.

I 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.

Would 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.

Dan

On Thu, Sep 18, 2014 at 6:38 AM, J. Vuletich (mail lists) <
[email protected]> wrote:

>  Hi Dan,
>
> Quoting Dan Amelang :
>
>  Hi 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.
>
>  And, 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 Cuis
> fonts), I think that (sorted by visual quality):
>
> 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 >= 9
> 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.)
>
>  I know option 3) produces the best quality, I'm just interested in
>> the 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 fo

Re: [fonc] Morphic 3 defensive disclosure

2014-09-18 Thread J. Vuletich (mail lists)

Hi Dan,

(redending without attachs)

Quoting Dan Amelang :


Hi 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? And, 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.



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. https://dl.dropboxusercontent.com/u/13285702/M3-TTF.png is a  
sample image using just that font.

And, 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 M3-TTF.png, and the original  
https://dl.dropboxusercontent.com/u/13285702/M3.png , and comparing  
with FreeType samples (for example, the regular Cuis fonts), I think  
that (sorted by visual quality):


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 >= 9
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.)




I know option 3) produces the best quality, I'm just interested in the
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



Dan

On Wed, Sep 17, 2014 at 6:25 AM, J. Vuletich (mail lists) <
[email protected]> wrote:


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 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 ).

Cheers,
Juan Vuletich

Quoting Dan Amelang :

 Hi 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)
 wrote:


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
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
[email protected]
http://vpri.org/mailman/listinfo/fonc


__

Re: [fonc] Morphic 3 defensive disclosure

2014-09-17 Thread Dan Amelang
Hi 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? And, 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.

I know option 3) produces the best quality, I'm just interested in the
visual details. Such a comparison might also be helpful to showcase and
explain your work to others.

Dan

On Wed, Sep 17, 2014 at 6:25 AM, J. Vuletich (mail lists) <
[email protected]> wrote:

> 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 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 ).
>
> Cheers,
> Juan Vuletich
>
> Quoting Dan Amelang :
>
>  Hi 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)
>>  wrote:
>>
>>> 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
>>> 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
>>> [email protected]
>>> http://vpri.org/mailman/listinfo/fonc
>>>
>> ___
>> fonc mailing list
>> [email protected]
>> http://vpri.org/mailman/listinfo/fonc
>>
>
>
>
>
___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc


Re: [fonc] Morphic 3 defensive disclosure

2014-09-17 Thread 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 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 ).


Cheers,
Juan Vuletich

Quoting Dan Amelang :


Hi 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)
 wrote:

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
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
[email protected]
http://vpri.org/mailman/listinfo/fonc

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc




___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc


Re: [fonc] Morphic 3 defensive disclosure

2013-12-06 Thread J. Vuletich (mail lists)


Hi Shawn, 

It is not aliasing that is different, but the algorithms for rasterization. 
When doing ray tracing for a 3d scne, you don't have an analytical model of the 
function to be sampled. 

Quoting Shawn Morel : 

> On Dec 6, 2013, at 6:58 AM, J. Vuletich (mail lists) 
>  wrote: 
>
>
> > Stochastic sampling (1) is a method for trading aliasing for noise. Result 
> > are neither alias free nor noise free. But it allows using Ray Tracing and 
> > related techniques, and that is great for photorealistic rendering of 3D 
> > stuff. This the kinds of problems Pixar works on.
>
> I?m actually curious to understand the distinction here between aliasing from 
> rays sampling the 3d scene (geometry intersection, texture UV mapping, env 
> lighting etc) and how that?s different from sampling a continuous function to 
> figure out pixel coverage.  
>
>
> shawn

Cheers,
Juan Vuletich___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc


Re: [fonc] Morphic 3 defensive disclosure

2013-12-06 Thread Shawn Morel

On Dec 6, 2013, at 6:58 AM, J. Vuletich (mail lists)  
wrote:

> Stochastic sampling (1) is a method for trading aliasing for noise. Result 
> are neither alias free nor noise free. But it allows using Ray Tracing and 
> related techniques, and that is great for photorealistic rendering of 3D 
> stuff. This the kinds of problems Pixar works on.


I’m actually curious to understand the distinction here between aliasing from 
rays sampling the 3d scene (geometry intersection, texture UV mapping, env 
lighting etc) and how that’s different from sampling a continuous function to 
figure out pixel coverage.

shawn___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc


Re: [fonc] Morphic 3 defensive disclosure

2013-12-06 Thread J. Vuletich (mail lists)

Hi Gath,

Stochastic sampling (1) is a method for trading aliasing for noise.  
Result are neither alias free nor noise free. But it allows using Ray  
Tracing and related techniques, and that is great for photorealistic  
rendering of 3D stuff. This the kinds of problems Pixar works on.


OTOH, I focus in 2D vector graphics, and not in 3D rendering. And yes,  
common implementations of OpenGL and libraries such as Cairo and AGG  
don't do prefiltering (called 'Analytical Algorithms' by Cook).


I hope this helps.

Cheers,
Juan Vuletich

(1)  
http://www.cs.virginia.edu/~gfx/Courses/2003/ImageSynthesis/papers/Sampling/Stochastic%20Sampling%20in%20Computer%20Graphics.pdf


Quoting Gath-Gealaich :


On Tue, 03 Dec 2013 23:24:12 -0300
"J. Vuletich (mail lists)"  wrote:


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
and http://ip.com/IPCOM/000232657 ..

Morphic 3 is described at
http://www.jvuletich.org/Morphic3/Morphic3-201006.html


On http://www.jvuletich.org/Morphic3/Morphic3-201006.html, you claim:


Anti-aliasing is usually considered a technique to avoid "stairway"
artifacts on rendered images. This is a simplistic view on the
problem. Aliasing is a consequence of sampling continuous functions
(images, photos, sound, etc). Makers of digital cameras and audio
software know and use the theory behind it. You can read more at
http://en.wikipedia.org/wiki/Nyquist–Shannon_sampling_theorem.



Researches know all this. The best text books say it. However,
existing graphics software completely ignore the theory.



... This allows for mathematically proved alias free rendering. As no
existing application does this ...


I'm sort of puzzled by this. I've always thought that this was the
whole idea behind the stochastic sampling thingy that the ILM/Pixar
people patented (http://www.google.com/patents/US4897806) in the 1980's
to achieve mathematically proven alias-free rendering (as you said) of
arbitrarily shaded arbitrary geometry (even shaded with non-analytical
functions). Of course, it trades aliasing for noise, but I believe
that you can have the noise arbitrarily low (and for animations, it may
not matter all that much anyway since one can expect some grain or
noisiness on live footage so completely noise-free sampling may even
look unnatural). They certainly didn't ignore the problem; they had
been studying numerous analytical and non-analytical solutions for a
better part of the 1980s and then finally striked gold with stochastic
sampling and PRMan.

-- Gath
___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc





Cheers,
Juan Vuletich

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc


Re: [fonc] Morphic 3 defensive disclosure

2013-12-05 Thread Gath-Gealaich
On Tue, 03 Dec 2013 23:24:12 -0300
"J. Vuletich (mail lists)"  wrote:

> 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
> and http://ip.com/IPCOM/000232657 ..
> 
> Morphic 3 is described at  
> http://www.jvuletich.org/Morphic3/Morphic3-201006.html

On http://www.jvuletich.org/Morphic3/Morphic3-201006.html, you claim:

> Anti-aliasing is usually considered a technique to avoid "stairway"
> artifacts on rendered images. This is a simplistic view on the
> problem. Aliasing is a consequence of sampling continuous functions
> (images, photos, sound, etc). Makers of digital cameras and audio
> software know and use the theory behind it. You can read more at
> http://en.wikipedia.org/wiki/Nyquist–Shannon_sampling_theorem.

> Researches know all this. The best text books say it. However,
> existing graphics software completely ignore the theory.

> ... This allows for mathematically proved alias free rendering. As no
> existing application does this ...

I'm sort of puzzled by this. I've always thought that this was the
whole idea behind the stochastic sampling thingy that the ILM/Pixar
people patented (http://www.google.com/patents/US4897806) in the 1980's
to achieve mathematically proven alias-free rendering (as you said) of
arbitrarily shaded arbitrary geometry (even shaded with non-analytical
functions). Of course, it trades aliasing for noise, but I believe
that you can have the noise arbitrarily low (and for animations, it may
not matter all that much anyway since one can expect some grain or
noisiness on live footage so completely noise-free sampling may even
look unnatural). They certainly didn't ignore the problem; they had
been studying numerous analytical and non-analytical solutions for a
better part of the 1980s and then finally striked gold with stochastic
sampling and PRMan.

-- Gath
___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc


Re: [fonc] Morphic 3 defensive disclosure

2013-12-05 Thread Josh Grams
On 2013-12-04 10:56PM, J. Vuletich (mail lists) wrote:
> Hi Josh,
>
> I've checked it again just in case. The diagram says that
> (w-r) < w < (w+r)
> (w-r+r+r) = (w+r)
> I think your comment is not correct. Please take another look at the figure.

Oh, wow.  I totally read that diagram wrong.  Sorry.

--Josh
___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc


Re: [fonc] Morphic 3 defensive disclosure

2013-12-04 Thread J. Vuletich (mail lists)

Hi Josh,

I've checked it again just in case. The diagram says that
(w-r) < w < (w+r)
(w-r+r+r) = (w+r)
I think your comment is not correct. Please take another look at the figure.

Cheers,
Juan Vuletich

Quoting Josh Grams :


On 2013-12-03 11:24PM, J. Vuletich (mail lists) wrote:

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
and http://ip.com/IPCOM/000232657 ..


In figure 3, you need to use 2r or r/2 in some places; currently
the diagram declares that r = 2r.

--Josh
___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc





Cheers,
Juan Vuletich

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc


Re: [fonc] Morphic 3 defensive disclosure

2013-12-04 Thread J. Vuletich (mail lists)

Hi Dan,

I'd be delighted to help you do that!

Cheers,
Juan Vuletich

Quoting Dan Amelang :


Hi 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)
 wrote:

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
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
[email protected]
http://vpri.org/mailman/listinfo/fonc

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc





Cheers,
Juan Vuletich

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc


Re: [fonc] Morphic 3 defensive disclosure

2013-12-04 Thread Josh Grams
On 2013-12-03 11:24PM, J. Vuletich (mail lists) wrote:
> 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
>  
> and http://ip.com/IPCOM/000232657 ..

In figure 3, you need to use 2r or r/2 in some places; currently
the diagram declares that r = 2r.

--Josh
___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc


Re: [fonc] Morphic 3 defensive disclosure

2013-12-04 Thread Dan Amelang
Hi 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)
 wrote:
> 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
> 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
> [email protected]
> http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc