Pixelperfect HTML font rendering

381 views
Skip to first unread message

Manfred Karrer

unread,
Apr 19, 2012, 8:13:06 PM4/19/12
to haxe...@googlegroups.com
Hi guys,

I posted on my blog some ideas about the font rendering problems in HTML Peter Halacsy presented at the conference. 

Here just a super-short summary:
- use embedded fonts for every browser with manipulated font metrics to get the same screen display
- create a font metrics table to get the metrics per font

The detailed description is at my blog:
http://nucleo.io/2012/04/20/pixelperfect-html-font-rendering/

saludos,
Manfred

Philippe Elsass

unread,
Apr 20, 2012, 3:06:11 AM4/20/12
to haxe...@googlegroups.com

I just think haxe could have a cross platform vector text tenderer - it would then naturally look the same (except for anti aliasing) on all targets.

But that's really only needed for Prezi-like contexts.

Jason O'Neil

unread,
Apr 20, 2012, 3:19:16 AM4/20/12
to haxe...@googlegroups.com

Good typography helps in every context!

Sorry, design major :P

...

Sent from my phone, so apologies for any typos...

Philippe Elsass

unread,
Apr 20, 2012, 3:37:19 AM4/20/12
to haxe...@googlegroups.com

@Jason sure, that's why I prefer to use the OS' text rendering instead of hacking the fonts ;)

Piergiorgio Niero

unread,
Apr 20, 2012, 5:16:14 AM4/20/12
to haxe...@googlegroups.com
Hi Manfred, hi guys.
Nice approach, but I think that the problem has to be split at the top: when users need pixel perfect typography? and whenever they need such a feature do they need text to be managed as text by the browsers?
I mean, pixel perfect is used mainly for drawing\printing programs (and flash :)) and often the same font is displayed differently from os to os. Further, one of the main reasons for having text managed as text on browsers is for website's seo. So, I would go for a pixel perfect rendering engine, just pick up freetype (which as far as I know is used for native font rendering by haxe) and port its rendering stuff to js... not immediate for sure, but it will fix the problem of pixel perfectness.
The problems in such a porting will be in vector rendering performances and\or availability, Franco at the conference underlined many times that vector rendering through svg is flawed and unsupported.

my 2 cents,
pigiuz

Niel Drummond

unread,
Apr 20, 2012, 5:42:50 AM4/20/12
to haxe...@googlegroups.com
My opinion is that a pure CSS solution is a good idea for performance,
and it's something I was considering because NME is very gaming
focused.

It will not get you a pixel perfect solution though, because you have
limited control over word wrapping, indentation, word spacing within a
justified line, and other sensibilities needed by the
print/publication industry.

I also don't think this is too specialized for NME, the publishing
industry does need better solutions for other platforms, there is more
to haxe than throwing the most number of bunnies around..

- Niel

--
Sent from my mobile device

Piergiorgio Niero

unread,
Apr 20, 2012, 5:58:53 AM4/20/12
to haxe...@googlegroups.com
I really don't get the comparison between "throwing the most number of bunnies" and "pixel perfectness"...

Manfred Karrer

unread,
Apr 20, 2012, 5:59:04 AM4/20/12
to haxe...@googlegroups.com
yes an own text rendering engine would be great but I also guess there will be too many problems regarding performance and browser support and it will be some considerable effort.

br,
manfred

blue...@gmail.com

unread,
Apr 20, 2012, 7:13:26 AM4/20/12
to haxe...@googlegroups.com
I like your idea on the blog, but am wondering if it's just the metrics that are different. Isn't shape somewhat handled differently aswell?  Also know that a font is not just a shape (like SVG) - but also includes a small program (bytecodes) that 'corrects' the looks for certain sizes.  If it were just shapes, small fonts would look terrible. The pixel/grid hinting bytecode fixes that.

Fortunately since May 2010, all patents related to bytecode hinting have expired worldwide. Starting with FreeType version 2.4, it is enabled by default. So we might just as well port freetype to haxe and have the exact same rendering engine on every platform :-P


Or, if you do not care about small fonts: render the font glyphs as vector shapes (canvas draw commands, swf draw commands, svg, choose your format) and it will also look the same on every platform.


Op vrijdag 20 april 2012 02:13:06 UTC+2 schreef Manfred Karrer het volgende:

James Jackson

unread,
Apr 20, 2012, 11:37:17 AM4/20/12
to haxe...@googlegroups.com
Interesting stuff raised here..

Optimising for High Pixel Density Displays.

James Jackson

unread,
Apr 20, 2012, 11:41:31 AM4/20/12
to haxe...@googlegroups.com
Also this is another intresting read about this topic..

How to Detect Font-Smoothing Using JavaScript

James Jackson

unread,
Apr 20, 2012, 11:46:42 AM4/20/12
to haxe...@googlegroups.com
Also this tool for XDA might help for creating bitmap fonts. Just need to port the C# code to pure Haxe.

"The BMFontGen application is a command line utility which can convert a TrueType or OpenType font into a bitmap font."

Creating Bitmap Fonts using bmfontgen

Jan_Flanders

unread,
Apr 20, 2012, 11:59:36 AM4/20/12
to haxe...@googlegroups.com
The hxswfml lib has a ttf2hx class which converts ttf data to flash.display.Graphics drawing commands for each glyph:
http://code.google.com/p/hxswfml/

You can try it online here:
http://www.haxer.be/fontwriter/index.swf

It outputs a zip with a hx class per glyph:
http://www.haxer.be/fontwriter/Char65.hx

You can write/draw them like:
http://www.haxer.be/fontwriter/ChopinScript.swf

FWIW...

Jan

PS: Nicolas has asked me a few months ago to put it in hxformat, but I still haven't found time to clean up the code and commit. :s

Rob Fell

unread,
Apr 20, 2012, 1:21:10 PM4/20/12
to haxe...@googlegroups.com
Perhaps a little off topic to the technology, but I felt the universal text consistency / "slight differences not acceptable" requirement by Prezi was an oxymoron.  If multi device, distributed team, multi perspective collaboration is the strategic priority then "pixel perfect text" is an unnecessary constraint longer term (not due to rendering technique but due to language variance & semantics).
 
Games developers know: "no text is best" therefore context rules.

Mihail Ivanchev

unread,
Apr 20, 2012, 1:51:24 PM4/20/12
to haxe...@googlegroups.com
Yeah this is basically everything they need. Unify the Graphics drawing across platforms (not easy I guess :P) and they are done. I suggested to them on the conference to use a PostScript interpreter and something similar to a lightweight LaTeX, but hxswfml is indeed many times better. Thanks for pointing it out, I'll use it for my future projects.

Reply all
Reply to author
Forward
0 new messages