Re: [fonc] Morphic 3 defensive disclosure
Hi Dan, (redending without attachs) Quoting Dan Amelang daniel.amel...@gmail.com: 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) juanli...@jvuletich.org 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 daniel.amel...@gmail.com: 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) juanli...@jvuletich.org 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 fonc@vpri.org
[fonc] Earley Parsing Explained (incomplete first draft)
Hi, After spending months banging my head over Earley Parsing, I have decided to write a tutorial. Ian once said Earley parsing is simple and easy to implement. I agree with simple, but not with easy. The required background knowledge is not trivial. This tutorial is an attempt to gather this knowledge in one place. Nothing fancy, no deep math, no proof of correctness. Just a (hopefully) intuitive explanation of the concepts, needed to implement Earley parsing. The goal is to help competent programmers who know little about parsing to write their own Earley parsing framework. So far, I have done most of the recogniser. The following pages are done, and up for review: http://loup-vaillant.fr/tutorials/earley-parsing/ http://loup-vaillant.fr/tutorials/earley-parsing/what-and-why http://loup-vaillant.fr/tutorials/earley-parsing/chart-parsing http://loup-vaillant.fr/tutorials/earley-parsing/recogniser Questions and criticisms are most welcome. I'd like to know about any factual inaccuracy, poor wording, confusing explanation… please don't hesitate to question anything, even the structure of this tutorial. Enjoy, and thanks, Loup. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Earley Parsing Explained (incomplete first draft)
On 19 Sep 2014, at 7:11 am, Loup Vaillant-David l...@loup-vaillant.fr wrote: Hi, After spending months banging my head over Earley Parsing, I have decided to write a tutorial. Ian once said Earley parsing is simple and easy to implement. I agree with simple, but not with easy. The required background knowledge is not trivial. Easy is pretty subjective! What's easy to my a 6 year old is not going to be easy for a 50 year old, and vice versa. Perhaps you mean approachable to someone of average intellect and cultural heritage? This tutorial is an attempt to gather this knowledge in one place. Nothing fancy, no deep math, no proof of correctness. Just a (hopefully) intuitive explanation of the concepts, needed to implement Earley parsing. The goal is to help competent programmers who know little about parsing to write their own Earley parsing framework. So far, I have done most of the recogniser. The following pages are done, and up for review: http://loup-vaillant.fr/tutorials/earley-parsing/ http://loup-vaillant.fr/tutorials/earley-parsing/what-and-why http://loup-vaillant.fr/tutorials/earley-parsing/chart-parsing http://loup-vaillant.fr/tutorials/earley-parsing/recogniser Questions and criticisms are most welcome. I'd like to know about any factual inaccuracy, poor wording, confusing explanation… please don't hesitate to question anything, even the structure of this tutorial. Enjoy, and thanks, Loup. I really like your writing style! One criticism I'd have is there aren't any pointers to people who don't have programming language construction backgrounds. So, perhaps adding a pre-requisite reading list at the beginning aimed at bringing someone who has finished high school and nothing else up to speed... This is perhaps my general criticism of most technical work. The assumed knowledge is high, and it shouldn't be. As more and more people get involved in computing, this means there can be less and less assumed backgrounds. I wrote about good code and by extension good writing a while back here: http://www.genericoverlords.com/good_coding Julian http://www.getcontented.com.au/ - You Need GetContented - Get Your Website Happy. :)___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Morphic 3 defensive disclosure
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) juanli...@jvuletich.org wrote: Hi Dan, Quoting Dan Amelang daniel.amel...@gmail.com: 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 for vector graphics too, as text is done simply by
