238039 - Integrate Mozilla with Innotek Font Engine

Status: RESOLVED FIXED

(Core Graveyard :: GFX: OS/2, defect)

Description

[jhp (no longer active)]

The Innotek Font Engine (http://www.innotek.de/products/ft2lib/) is a FreeType2
based engine that provides anti-aliasing of fonts on OS/2.  In addition, it
exports several functions which can be used by Mozilla in order have better font
support on OS/2.  The main thing the engine offers is that we can query whether
a font supports a given glyph.

Comment 1

[jhp (no longer active)]

Attachment: patch v1

In addition to the code that links to and uses the FT2LIB functions, this patch
also contains fixes for warning in gfx/src/os2 that were annoying me.

For the moment, since this patch has not been tested outside of my computer,
the user is required to set the environment variable
MOZILLA_USE_EXTENDED_FT2LIB=T in order to make use of the new code. 
Eventually, if all the kinks are worked out and the performance is good, then
I'll switch it on by default.

Comment 2

[jhp (no longer active)]

The patch also contains some code from the patch in bug 189480, so setting this
bug dependent on that one.

Comment 3

[Felix Miata]

I install v1 with every new nightly (but not with each most recent release, in
part in order to see "the other way").

<Devil's advocate>It would be nice for people with slow puters to retain an
option to disable the signifcant overhead using ft2lib imposes. Minimum CPU
requirement for Mozilla remains Pentium-133 class. (I'd hate to have to
routinely run with ft2lib enabled on one of those, or even on a 300.)

Also, if running high resolution (1400x1050 or higher) and commensurate size
default fonts, there isn't nearly as much improvement in font appearance with
over without (AFAICT). A few might rather have more speed there than the small
improvement.</Devil's advocate>

Comment 4

[jhp (no longer active)]

This new code does not force you to use FT2LIB.  If you don't have it installed,
or if it is disabled for you application, then it just works like it has always
worked.

Comment 5

[jhp (no longer active)]

Attachment: patch v1.1

This patch (1) enables USE_EXPANDED_FREETYPE_FUNCS, which should result in
better performance since we don't need to convert from Unicode to UTF-8 before
calling the functions; (2) removes the symbol font check in
nsFontOS2FT::HasGlyph(), since the latest version of FT2LIB has fixed this
issue; and (3) disables bold/italic simulation for bitmap fonts since FT2LIB
currently does not handle this.

Comment 6

[jhp (no longer active)]

Attachment: patch v 1.2

Don't disable bold/italic simulation for bitmap fonts.

Comment 7

[jhp (no longer active)]

Attachment: patch v1.3

(1) Properly enable printing when MOZILLA_USE_EXTENDED_FT2LIB is set.
(2) Made GetTextExtentPoint32 and ExtTextOut helper functions return valid
success/failure values.

Comment 8

[jhp (no longer active)]

Attachment: patch v1.4

(1) No longer need to create converters for 1386/943 codepages in
nsFontMetricsOS2.cpp.
(2) Simplify #ifdefs in nsRenderingContextOS2.cpp.

Comment 9

[jhp (no longer active)]

Attachment: patch v1.5

(1) Always check if Ft2QueryTextBoxW() and Ft2CharStringPosAtW() fail with
PMERR_FUNCTION_NOT_SUPPORTED.
(2) Because of the above, we can get rid of all the special printing code added
in patch v1.3.
(3) Restore GpiMove() to ExtTextOut.  If the string was over 512 chars, it
would fail without GpiMove().

Comment 10

[jhp (no longer active)]

Attachment: patch v1.6

Updating patch to trunk now that bug 189480 has been checked in.

Comment 11

[Mike Kaply [:mkaply]]

Comment on attachment 146511 [details] [diff] [review]
patch v1.6

r=mkaply
sr=blizzard (platform specific)
a=mkaply (OS/2 only)

Comment 12

[Mike Kaply [:mkaply]]

Fix checked in.

Comment 13

[Benjamin Smedberg]

Comment on attachment 146511 [details] [diff] [review]
patch v1.6

>Index: gfx/src/os2/Makefile.in
>===================================================================
> 		nsGfxFactoryOS2.cpp \
> 		nsPrintOptionsOS2.cpp \
> 		nsGfxDefs.cpp \
>+		$(topsrcdir)/gfx/src/windows/nsUnicodeRange.cpp \
> 		$(NULL)

This is badly abusing the build system... the makefile will not be able to
track dependencies correctly. Please fix this by doing an nsinstall to the
current dir (during the export phase) and then making from there. There are
examples of this all over the tree (xpcom/glue/standalone is a good one)

Comment 14

[jhp (no longer active)]

Attachment: Makefile patch

Makefile patch based on bsmedberg's comments.

Comment 15

[Mike Kaply [:mkaply]]

Makefile change checked in.