491305 - Allow loading fonts from an application folder on Windows Mobile

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Mark Finkle (:mfinkle) (use needinfo?)]

Could we add a mechanism to load fonts from an application specific folder, in addition to the current loading methods?

Mobile would like to ship a font with the application and not actually install the font in the OS. The font code could use a nsIDirectoryProviderService tag to locate "other" font locations and load fonts from those locations.

Comment 1

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: adds the res dir to our font search path on wince

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

Can we make a general solution for this? Beyond just WinCE.

Comment 3

[Brad Lassey [:blassey] (use needinfo?)]

So, as Mark said, we want this for all platforms.  I only have a wince build environment set up right now, hence the wince only patch.

Comment 4

[Karl Tomlinson (:karlt)]

Comment on attachment 375627 [details] [diff] [review]
adds the res dir to our font search path on wince

I was wondering how this would interact with the EnumFontFamiliesExW call in gfxWindowsPlatform::ResolveFontName (as the system wouldn't know about this font directory), but this should work out OK because ResolveFontName always checks mFonts first.

There is already a res/fonts dir.  Would it make sense to use that?
Currently this dir doesn't have fonts but properties about fonts, used for MathML.
But it would seem strange to have a "fonts" subdir but put the fonts somewhere else.

>+        nsDependentString resPath;
>+        resDir->GetPath(resPath);
>+        searchPaths.AppendElement(resPath);

I think you mean "nsAutoString resPath" here.  (nsDependentString may happen to work but I don't think this is how it is meant to be used.)

Comment 5

[Karl Tomlinson (:karlt)]

(In reply to comment #3)
> So, as Mark said, we want this for all platforms.

I think this can probably be done for Pango and/or FreeType/GTK backends using

FcConfigAppFontAddDir(NULL, path)
http://fontconfig.org/fontconfig-devel/r2744.html

(config = NULL results in the default config being modified).

It might be worth checking the effect on startup, though.

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #4)
> There is already a res/fonts dir.  Would it make sense to use that?
> Currently this dir doesn't have fonts but properties about fonts, used for
> MathML.
> But it would seem strange to have a "fonts" subdir but put the fonts somewhere
> else.

This is probably the GRE_DIR/res/fonts folder (GRE == xulrunner in this case).
We need to make sure we use the APP, not GRE as the base folder. GRE == APP in
Firefox, but not for xulrunner based apps.

Comment 7

[Karl Tomlinson (:karlt)]

(In reply to comment #6)
> This is probably the GRE_DIR/res/fonts folder (GRE == xulrunner in this case).
> We need to make sure we use the APP, not GRE as the base folder. GRE == APP in
> Firefox, but not for xulrunner based apps.

Ah, thanks, and yes MathML uses resource://gre/res/fonts/mathfont.

There may still be some value in using a fonts subdir though as FcConfigAppFontAddDir would open each file in the dir (to test whether it is a font).

Comment 8

[Brad Lassey [:blassey] (use needinfo?)]

For Windows desktop we can search the directory ourselves and use AddFontResourceEx with FR_PRIVATE, which will make sure that only the application with the fonts can use them.

So I guess the only question remaining is cocoa, which I have no experience with.

Comment 9

[Jonathan Kew [:jfkthame]]

It should be straightforward to do this on OS X using ATSFontActivateFromFileReference with the kATSFontContextLocal option. (Not really a Cocoa API, this is part of ApplicationServices, IIRC.)

I'm curious what the specific use case is, however. I'm a bit concerned there may be a significant performance hit to using this kind of "font activation" API (on any or all platforms), as it may cause the underlying font system (whether GDI, fontconfig, or ATS) to discard and rebuild font name and property caches that are normally shared across all applications.

Comment 10

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: a patch for windows desktop

Comment 11

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I would rather do this only on the FT2 font backend rather than everywhere, though I don't have a good reason why not.. and there might be good reasons why (e.g. a user can install fonts that can be web-accessible without being able to install fonts system wide or something).

Comment 12

[Brad Lassey [:blassey] (use needinfo?)]

Mark seems to want to add this as a feature of xulrunner, which makes sense to me because native applications can have "private" fonts.  If we do it for any platforms I'd prefer to do it for all platforms.

Comment 13

[Jonathan Kew [:jfkthame]]

(In reply to comment #12)
> Mark seems to want to add this as a feature of xulrunner, which makes sense to
> me because native applications can have "private" fonts.

I'd be interested in hearing about specific use cases where we think this is needed; to me the idea of applications having "private" fonts runs directly counter to user expectations on modern GUI platforms, where fonts are a "universal" resource available across all applications. The exception would be fonts that are tied to a particular document (e.g. embedded in a PDF), and for this in the context of web content we have @font-face.

It's true that some power users with lots of fonts like to activate and deactivate them according to the needs of particular projects, but font activation is normally a global operation.

Comment 14

[Jonathan Kew [:jfkthame]]

(In reply to comment #0)

> Mobile would like to ship a font with the application and not actually install
> the font in the OS.

Which font, and why? I'd like to understand the use case better.

Comment 15

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to comment #14)
> > Mobile would like to ship a font with the application and not actually install
> > the font in the OS.
> 
> Which font, and why? I'd like to understand the use case better.

On many Windows Mobile/Windows CE devices it's actually impossible for the user to install fonts into the system.  The system often comes with a very basic set of fonts, and we want a richer set available for the web (at least, supporting a wider set of unicode code points).  I think the idea was to ship the Droid and/or Bitstream Vera (perhaps DejaVu or something) fonts to avoid these problems, and to allow users to better control this.

Comment 16

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #14)
> (In reply to comment #0)
> 
> > Mobile would like to ship a font with the application and not actually install
> > the font in the OS.
> 
> Which font, and why? I'd like to understand the use case better.

As Vlad said, fonts on mobile devices can be fairly crappy and installation of fonts may not be easy. We are thinking of shipping a Droid Family font. If we do, we might want to use it on all Mobile platforms, currently Windows Mobile (freetype) and Maemo (fontconfig?).

Jonathan is raising good points. Aside from controlling the UI font in an @font-face like manner, I have no other use cases. If we decide to do this on 1 or 2 platforms, I would push to support it on the others for consistency as well - as long as support is not overly difficult.

Comment 17

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

FWIW, I still disagree that we want this on all platforms.  Maybe we could do it controlled by a pref that's off by default, that certain fennec platforms would ship enabled.

But, I think it's essential for mobile and many other constrained environments (e.g. think of some environment that doesn't support truetype fonts at all natively, just bitmap fonts).

Comment 18

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to comment #6)
> (In reply to comment #4)
> > There is already a res/fonts dir.  Would it make sense to use that?
> > Currently this dir doesn't have fonts but properties about fonts, used for
> > MathML.
> > But it would seem strange to have a "fonts" subdir but put the fonts somewhere
> > else.
> 
> This is probably the GRE_DIR/res/fonts folder (GRE == xulrunner in this case).
> We need to make sure we use the APP, not GRE as the base folder. GRE == APP in
> Firefox, but not for xulrunner based apps.

Really?  I would think that you would want the GRE res/fonts dir if you had to pick one, or ideally look in both.

Comment 19

[Brad Lassey [:blassey] (use needinfo?)]

marking as blocking fennec 1.0 for winmo since this looks like the best work around for bug 479548.

Karl and Stuart, can you do the reviews so we can move forward on this?

Comment 20

[Karl Tomlinson (:karlt)]

Comment on attachment 375627 [details] [diff] [review]
adds the res dir to our font search path on wince

I think it would make sense to have a "fonts" subdir, so that fewer files need to be scanned for their type, but I'm passing this review to vlad because I think he is a better person to make this decision.  (Looking in both APP and GRE makes sense to me, but I guess GRE doesn't need to be added until it's needed.)

Comment 21

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 375627 [details] [diff] [review]
adds the res dir to our font search path on wince

Yes, fonts folder absolutely; res/fonts.

Comment 22

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: uses res/fonts

Comment 23

[Karl Tomlinson (:karlt)]

Comment on attachment 393722 [details] [diff] [review]
uses res/fonts

>+        nsDependentString resPath;
>+        resDir->GetPath(resPath);

I'm pretty sure that should be nsAutoString resPath.

Comment 24

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to comment #23)
> (From update of attachment 393722 [details] [diff] [review])
> >+        nsDependentString resPath;
> >+        resDir->GetPath(resPath);
> 
> I'm pretty sure that should be nsAutoString resPath.

I landed the patch that vlad reviewed:
http://hg.mozilla.org/mozilla-central/rev/bf206df7eff9

and a follow up for Karl's comment
http://hg.mozilla.org/mozilla-central/rev/57611d381ef4

This bug is now fixed for windows mobile (which is what I care about), but not any other platform.  Not sure if there is a way to reflect that in the status or whiteboard.

Comment 25

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Just add "with FT fonts" to the description and resolve this bug; if someone's motivated, they can file a new bug for other platforms.