Closed Bug 52746 (dynamicfonts) Opened 24 years ago Closed 14 years ago

Mozilla does not support dynamic fonts

Categories

(Core :: Layout: Text and Fonts, defect, P3)

defect

Tracking

()

RESOLVED FIXED
Future

People

(Reporter: nvshaji, Unassigned)

References

()

Details

(4 keywords, Whiteboard: relnote-devel)

Mozilla does not seem to support dynamic fonts like Netscape 4.x. Is it not
going to be supported ever? Most of Indian language websites uses dynamic fonts,
and if mozilla does not support it it will be ignored by everyone. See how
different the above website appear on mozilla and netscape 4.x(or IE)
I don't think it intends to either.
But that page freeze linux with following output

Error loading URL http://www.malayalamanorama.com/: 804b0002
Gdk-ERROR **: BadValue (integer parameter out of range for operation)
  serial 533764 error_code 2 request_code 45 minor_code 0
Gdk-ERROR **: BadFont (invalid Font parameter)
  serial 533765 error_code 7 request_code 47 minor_code 0


Even if it doesn't angle dynamic fonts, it shouldn't hang like that.
Had to kill it - 97/99% CPU as usual.
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.malayalamanorama.com%2F -
shows errors in the dynamic fonts code.

Since this works in 4.7x, sending to DOM 0. However, I understand that we don't
support this now.
Assignee: asa → jst
Status: UNCONFIRMED → NEW
Component: Browser-General → DOM Level 0
Ever confirmed: true
QA Contact: doronr → desale
This is not a DOM problem, Chris, any idea who this should go to?
Assignee: jst → waterson
erik, is this you?
Assignee: waterson → erik
We have no plans for dynamic fonts in Netscape 6. I don't know of any
mozilla.org activity in this area either. Accepting bug for now, with milestone
Future.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
adding keyword relnoteRTM. Dynamic fonts are widely used.
Whiteboard: relnote-devel
*** Bug 67459 has been marked as a duplicate of this bug. ***
Assignee: erik → trudelle
Status: ASSIGNED → NEW
Component: DOM Level 0 → XP Toolkit/Widgets
OS: Windows 98 → All
QA Contact: desale → jrgm
Hardware: PC → All
Toolkit?  helpwanted !!
If ever implemented (unlikely), it would be done in core layout
-> back to erik, layout, still Future
Assignee: trudelle → erik
Component: XP Toolkit/Widgets → Layout
QA Contact: jrgm → desale
Mozilla should support it in exactly the same way (if possible) that IE does so 
there is some kind of fonts standard on the internet.
*** Bug 75204 has been marked as a duplicate of this bug. ***
Mozilla is like Internet Explorer: neither supports dynamic fonts.
Would not it be a better idea to make it like Netscape Communicator?
*** Bug 76345 has been marked as a duplicate of this bug. ***
CCing Frank Tang who I believe is working on this.

related bugs, I'm not sure which should be marked as duplicates:
bug 41250
bug 65904
*** Bug 78084 has been marked as a duplicate of this bug. ***
erik resign. reassign all his bug to ftang for now.
Assignee: erik → ftang
mark all future new as assigned after move from erik to ftang
Status: NEW → ASSIGNED
*** Bug 62831 has been marked as a duplicate of this bug. ***
*** Bug 65904 has been marked as a duplicate of this bug. ***
*** Bug 106766 has been marked as a duplicate of this bug. ***
If this is going to be fixed, it should of course be done in accordance with the
CSS2 specification, and not "like in 4.7". 

It worries me if you aren'tplanning to support CSS2 fully.
This bug should be fixed. Dynamic fonts should be supproted. IE does support
dynamic fonts(proof: Try www.eenadu.net on IE and mozilla and see the diference
IE displays correctly). So don't expect that mozilla not supporting dynamic
fonts will discourage anybody from not using dynamic fonts. 

This bug limits the usage of mozilla to English speaking countries. Also 4.7x
supports dynamic fonts so we might loose some of those actually using netscape4.7x
(See also bug # 59611)
I have called BitStream to go open source with the TrueDoc PFR technology
for the benefit of the Mozilla project, and they indicated they're ready
to do so. Please see my article on this topic at

http://www.tarunz.org/~vassilii/BitStream.html
i visited a site eenadu.net, using the build 2002030803, which is using dynamic
fonts, but the page is not displayed properly. While this page is being shown
properly in IE. 
Keywords: intl
using moz1.0 on winme.

still no dynamic fonts!  to put this straight, dynamic fonts *are* part of css2,
and *are* supported by both ie (since at least version 4) and netscape 4.x.

what is the issue here?  if it is a proprietary one, then this bug should be
shifted to a different component.

we're not only leaving a lot of international users out in the lurch with this,
but it doesn't look too good when 4+ year-old browsers work better than the
"official release" version.

strongly suggest increasing priority or *something* to put this back on the
radar.  keyword 4xp, too, just to rub our noses in it.  ;)
What's the status of this bug? Is the Bitstream option viable?
Keywords: 4xp, css2
What's the status? Is Bitstream still interested in open-sourcing TrueDoc? CSS2
supports Truedoc *and* EOT, it's a rather important feature for standard
compliance sake.

NS4.x used to be able to view EOT also by means of the generic Active-X bridging
plugin as far as I can remember.
"to put this straight, dynamic fonts *are* part of css2,"

Wait a minute. Last I checked, there *was* the ability to include a font file in
CSS2, but there was *no* clearly defined *format* for that.

Assignee: are you still working on this?
*** Bug 174540 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.2mozilla1.4
This bug has been tossed around for more than two years. Meanwhile, my company 
has moved on and last month we decided to use Internet Explorer because it 
supports dynamic fonts (on the PC platform, at least).

Yes, CSS2 supports dynamic fonts. There's even a syntax, thought it takes some 
digging through the documentation to assemble all of the proper syntax.

And Bitstream says they'll put the technology into the public domain, if asked 
to do so.

So why doesn't this bug ever get resolved?
The barrier is that no developer has done the work. That means a lack of money,
interest, or time. 

If someone steps up to the plate and does the work, and the code is good, I'm
positive it will be not only be checked in, but also the developer and his
sponsor will have the gratitude of the entire Mozilla community. 

You, or your company, or anyone is welcome to hire a developer to write that code.
Flags: blocking1.3a+
Flags: blocking1.3a+
==> Fonts/text
Component: Layout → Layout: Fonts and Text
QA Contact: desale → ian
Keywords: testcase
*** Bug 174324 has been marked as a duplicate of this bug. ***
*** Bug 196907 has been marked as a duplicate of this bug. ***
i18n triage team: nsbeta1-
Keywords: nsbeta1nsbeta1-
*** Bug 189569 has been marked as a duplicate of this bug. ***
It's not worth to mention "lack of money, interest, or time", etc. Many
languages have to use embedding fonts. MS WEFT resolves this problem but in
their wicked manner. According to W3C/CSS2 any CSS2-browser should use
@font-face rule to specify font description
(http://www.w3.org/TR/REC-CSS2/fonts.html#font-descriptions). This rule
specifies to use embedding fonts .pfr, .eot, .pfb, .pfa, .ttf.

It's strange why mozilla community hadn't time or interest to resolve that
problem for two years
Sorry to spam the bug but my annoyance threshhold was finally crossed. I too am
anxious for Mozilla to support dynamic fonts, but the purpose of dynamic fonts
is *not* to support international charsets! If you need dynamic fonts for that,
you're coding your page (or configuring your server) wrong. Mozilla, unlike
Netscape 4 and below (but like IE), is very good about correctly picking an
appropriate font for your language, *provided you have specified the charset
correctly*. You will note that *neither* of the sites listed in the URL field of
this bug do so. 

To see an international site that renders correctly, go to the site I maintain,
<http://www.bignews.org/>. You'll note that the Chinese characters display fine,
even in the plaintext files that are linked from the main page. Go to
<http://www.w3.org/International/O-HTTP-charset> and
<http://www.htmlhelp.com/tools/validator/charset.html> to see how to specify
character sets. This bug is a *design* issue, not an internationalization one. 

Since I'm barking anyway, I'd like to clear up a couple things. IE does support
dynamic fonts, and it does it correctly; it's completely in keeping with the
CSS2 spec. Yes, it only supports its proprietary .eot pseudo-font files, but
that doesn't make it any more non-compliant than if it didn't support .png
files. Netscape 4 did support dynamic fonts in some versions, but it did it in a
non-compliant way; there was no way you could include them without writing
invalid HTML. There's nothing wrong with the Bitstream format, though, and no
reason why Bitstream .pfr files couldn't be supported through the proper CSS2
way. For that matter, there's no reason .ttf files couldn't be supported that
way. Yes, there are copyright issues, but I don't see why that's the browser's
problem. There are plenty of public domain TTF files; why can't I embed them in
my page? Mozilla still loads my jpegs, even though I might have stolen them.

comment 28 has been bugging me, too. Why would the CSS spec specify the file
format for embedded fonts? That's not the purpose of CSS, and it doesn't specify
the file format for images, sounds, or anything else.

Okay, that's it, except that people should stop complaining about this not being
fixed. The bug's here, people are voting for it, there are a lot of dupes, it'll
get done eventually, and whining won't speed anything up. If you really want to
get it fixed and can't code, take up a collection to hire a coder like they did
in bug 17048 (which is now close to being fixed).
"provided you have specified the charset correctly"

What is the correct charset specification for Tengwar, a script that
has not yet been accepted into Unicode?

And how much would you estimate that it would cost to fix this bug?
I'll say it again: Why should my company spend a penny to fix this bug when we 
can simply switch to IE? In fact, that's what we did.

I could argue about investing time and money to help Mozilla fix it, but the 
answer is obvious: My company uses the best tools for the job, and Mozilla 
without dynamic fonts is not the best tool. IE is free, so we switched.

Philisophical arguments hold little sway against financial arguments. Netscape 
must finance this fix or they will continue losing clients to IE. It's that 
simple.
I think font-face support is bug 70132.
Walter, if you feel that Netscape should finance this fix, I would suggest
contacting Netscape and letting them know that... Mentioning it in a bug in a
non-Netscape bug database is not likely to get the attention of the
purse-string-keepers at Netscape (at best, it will be seen by a Netscape
developer who has no power to make such decisions anyway).  Contacting Netscape
management directly, one company to another, would be much more effective...
Depends on: 70132
*** Bug 202267 has been marked as a duplicate of this bug. ***
*** Bug 206763 has been marked as a duplicate of this bug. ***
re: comment #40

Walter,

RE: CHOICE OF BROWSER
Certainly, depending on the situation, Mozilla, IE or both are appropriate tools.

In your situation, Mozilla apparently has a disadvantage:  It doesn't support
dynamic fonts.  

It also has several advantages:  For example, in your situation (if you work for
the NY Times as your e-mail address implies), I would think privacy and security
of data would be paramount; certainly, software that opens security holes on
reporters computers would be a serious problem.  IE has a poor reputation for
security and privacy.

You say IE is free, but that's only to buy.  Consider also the cost to deploy,
support, and integrate with other systems.  Those costs depend on your
situation, also.  Mozilla's greater stability and security reduces support
costs; its cross-platform nature reduces some integration costs, but of course
IE is compatible with more proprietary back end systems.


RE: OPEN SOURCE DEVELPOMENT MODEL
You ask, "Why should my company spend a penny to fix this bug"?

The answer to your question seems obvious:

Why should the NY Times (again, if that's who you represent) give back to the
community?   A community that promotes the ability of people to freely, as in
beer and speech, communicate?  Does the NY Times really want all Internet
communication to flow through one, commercial, gatekeeper?


I very much like the newspaper, by the way.
Walter - 

I should add, though I probably shouldn't belabor this off-topic point:

Some day, who knows when, most news will be read via the Internet.  On that day,
without Moz or some alternative browser, readers will have to go through
Microsoft to get to the NY Times.

Are they a trustworthy partner?  They have quite an agressive track record. 
What happens when IE comes with it's own search engine and home page (e.g. MSN),
and responding to criticism in the Times, removes nytimes.com from their search
engine and other links.

Readership that day will drop to AOL and the dozen or so Opera users. 
Alternative browsers seem to me to be essential for your business.

I'm curious as to why the New York Times Company needs dynamic font support. 
Putting the page's language and encoding in the header will render a page 
automatically and properly in that language on both IE and Mozilla as long as 
the device has a font for that character set. Specifying the encoding and 
charset in the document's markup will do the same, and let you render 
multilingual pages just fine, too.

The second (and perhaps original) purpose of dynamic fonts was to get pretty-
looking, smooth, antialiased font rendering on pages. This is now done at the 
operating system level on WinXP, MacOS X and most Unixes.

The only solid, legit uses for dynamic fonts going forward are still good 
reasons to have it: (1) making it possible to read any language on any PC--even 
a securely locked-down one, so an Armenian wor Gujarati traveler can walk into 
a cybercafe in South Korea or Brazil and read her or his hometown websites, and 
(2) so the NY Times, for instance, can display its masthead in its trademark 
typeface without using a graphic.

Yes, this should be implemented--but I'm still curious as to the business 
reasons the NY Times Company finds it important to be able to render languages 
not read by the owners of a given PC and that still can't be typed on that PC.
*** Bug 209833 has been marked as a duplicate of this bug. ***
Alias: dynamicfonts
Um, I just tried this on a page that has CSS2 for both .eot and .ttf (though I
didn't think anybody supported it) and it rendered correctly on Mozilla 1.4 on
OS X!!??  Is the Mac font handling different than Mozilla for PC and Unix?  Why
can they do it correctly and Windows can't?
*** Bug 218661 has been marked as a duplicate of this bug. ***
*** Bug 222877 has been marked as a duplicate of this bug. ***
I came to this bug because a client of mine wanted his page to render using a 
font that is non-standard to PCs. It's not a foreign language font or anything 
weird. It just happens to be non standard on PCs, and probably Macs too. 
 
There are various things that IE does, some in the standards most not, which 
clients are finding `cool'. The knowledge about them is seeping out and I am 
finding that clients are wanting these features. Mozilla is the ONLY 
alternative to IE both on the Windows platform and others. I realise that 
standards come first but, given Mozilla increasing maturity, isn't it time to 
start considering cool and fun features ? 
If Mozilla is to support css2 and be of service to the 2 billion people of Asia,
it needs to support dynamic fonts. I strongly recommend it be treated as a
serious bug and that 1.8 not get released without it.
Sigh. Please see my previous comment 38. Dynamic fonts are *not* necessary for
internationalization. Properly-configured Asian-language sites render fine in
Mozilla, see <http://www.yahoo.co.jp/> and <http://www.bignews.org/20040401.txt>
for Japanese and Chinese examples, respectively.

This is a design feature request, not an internationalization bug.
If Mozilla is to support css2 and be of service to the 2 billion people of Asia,
it needs to support dynamic fonts. I strongly recommend it be treated as a
serious bug and that 1.8 not get released without it.
Kim, I did see your comment, but your comment is just plain wrong for South
Asia.  I've seen no such thing as an agreed upon Bengali font that people can
install and browse the web with. Find me one Bengali site that doesn't use
either dynamic fonts or pdf files and I might believe you. There are 220 million
Bengali's on our planet - most of them have lousy bandwidth, and are so really
tired of downloading pdfs. So what they are using is IE or Netscape 4.7 with
dynamic fonts.
> Find me one Bengali site that doesn't use either dynamic fonts or pdf files

Sure, here's one:

<http://www.stat.wisc.edu/~deepayan/Bengali/WebPage/Archive/Madhusudan/Chaturdashpadi/archive.bn.html>
> I've seen no such thing as an agreed upon Bengali font that people can install
and browse the web with.

Here's some free downloads of Bengali UTF-compliant fonts that people can
install and browse the web with:

<http://www.nongnu.org/freebangfont/>

Also, Arial Unicode, which comes with Microsoft Office, has Bengali support.
Microsoft used to offer it as a free download, but I can't find it anymore.

Anyway, sorry to waste everyone else's time with this but supporting
international character sets via font embedding is an awful practice that needs
to be stopped.

OK, I stand corrected! I'll now see if I can figure out how to convert our old
Bengali documents to Unicode, and we'll put them onto the web!
If this needs to be fixed to fully support CSS2, I agree with giving this a
higher priority.

The browser versions are churning out too fast in my opinion, giving not enough
time for feature additions and bringing us too close to version 2.0. Wouldn't
full support for CSS2 be something amiable for 2.0?

This bug also has 49 votes. Is Frank Tang still active or should we give this to
nobody@mozilla.org?

(In reply to comment #58)

Kim - If very few website use your solution (which is my impression -- correct
me if I'm wrong), no matter how technically superior it is, aren't we selling
Betamax?

Users want to use websites; if Moz doesn't work with many websites, and IE works
using an inferior technology, guess which browser the users will choose.
Sure, it works with Bengali, because the marketing department of Microsoft
Corporation has chosen to support Bengali in the company's popular operating
system. But then how does one write a web page in a script that the Microsoft
Windows operating system does not support?  For instance, how would I write and
publish a web page written in Tengwar script or any other script that is too
rare to make it into the Unicode standard?  Would I have to use one image per
letter or one image per line of text or something?
I've long since given up on getting dynamic fonts in Mozilla, and I moved 
my company to IE6 (another free browser). But for those of you who think 
dynamic fonts are some sort of neanderthal technology that should be 
stomped out -- or just something useless -- here were my reasons (some 
of which affect different aspects of my company's business):

1) I need the ability to display many fonts, including non-Unicode fonts. 
Using thousands of gif files is not practical for many reasons, and it does 
the end user no good either.

2) I'm not happy displaying the same generic fonts as everyone else. I 
need something the makes my web site stand out, and custom fonts do 
this. The only economical way to distribute custom fonts is via the 
dynamic font model of CSS. This way I bear the sole cost of the font 
licensing.

3) I want something that is CSS2 compatible (no cracks about Microsoft 
vs. the world's standards bodies, please); any browser that has written off 
dynamic fonts has also written off CSS2 compatibility.

4) I want to use CSS on a variety of output devices; in some cases, I want 
to swap out a dynamic screen font in favor of an embedded generic font 
when the user prints out the page. Try THAT with teenie-weenie GIFs!

5) Fonts are not just technical renderings of characters; they are works of 
art that should be afforded no less respect than, say, my company logo. 
To ask third-world users -- many of whom cannot affort to buy font libraries 
-- to tolerate a simple generic Unicode font for all of their web needs is 
just culturally insensitive and fails to take into account the complex 
linguistic needs of many "foreign" languages.

I sit on several XML standards committees, and I regularly vote on matters 
that affect users of non Latin-1 character sets. If I've learned anything, it's 
that they need all  the flexibility and creative tools that can be offered. 
Killing dynamic fonts is a step backwards, IMHO.
Glyph sets that aren't in the Unicode standard should be proposed to Unicode for
inclusion, and in the meantime, should use the Private Use Area. Note, though,
that this has nothing to do with this bug.

This bug is about @font-face and dynamic font download, a feature that will be
supported in Mozilla as soon as someone implements it (or pays someone to
implement it). The people who currently work on Mozilla do not consider this bug
a priority. This is unlikely to change, regardless of how much people say that
this is a critical feature in this bug.
(In reply to comment #64)
> The people who currently work on Mozilla do not consider this bug
> a priority. This is unlikely to change, regardless of how much people say that
> this is a critical feature in this bug.

It would be basic consideration if they'd make an argument about why not.

As one of many people who has contributed many hours to Mozilla, I don't
appreciate the decisions being handed down from on high and sans explanation.
guanxi: That's probably something for the newsgroups. You can post the response
here. The best they could probably due is give a list of other bugs, along with
directions being taken. Those who fix the bugs get to choose the priority. What
I don't agree with is if there is a patch written, and they don't check it in or
even look at it because they don't consider it high enough priority, but
something like this I can understand. No patch exists, and therefore they can
choose which bugs to write patches for first.
given the debate that seems to have emerged over this bug recently, it may be
helpful for someone to clarify whether a patch for this bug would even be
accepted.   if not, this bug should be marked invalid.

also, since the reasons in favor of patching this bug have been elucidated
clearly enough, it would be of benefit to establish the reason(s) why this bug
is considered to be a low (or lower) priority one, even if that reason is simply
a lack of interest amongst the mozilla developer community.  of course, perhaps
the lack of interest in opposing those supporting a patch may already signal that.



 
"Glyph sets that aren't in the Unicode standard ... in the meantime,
should use the Private Use Area. Note, though, that this has nothing
to do with this bug."

I am aware of a standardization of the Private Use Area for many
scripts that the Unicode Consortium has not yet added:
http://www.evertype.com/standards/csur/

But in such meantime, how would characters either
  1. in the Private Use Area, or
  2. in the Unicode standard but not in Microsoft's implementation,
get rendered on web pages without dynamic font support from the browser?
> But in such meantime, how would characters [...] get rendered on web pages 
> without dynamic font support from the browser?

The same way they would for Bengali -- by have the user install a font locally.
Assignee: ftang → nobody
Status: ASSIGNED → NEW
QA Contact: ian → core.layout.fonts-and-text
AND THEREIN LIES THE RUB: If we force users to download new fonts for possibly transient 
reasons (an Urdu speaker's brief visit to an Arabic page, perhaps), we shift the burden of 
cost -- buying the right font for the right platform -- to users who may be ill-equipped to 
afford it.  Regional, artistic and historical font variations are constant sources of 
frustration to both web designers and users; why kill off a useful tool like dynamic fonts?

Dynamic fonts allows the site owner the option of absorbing the cost of the fonts to be 
displayed; it allows the site designer to use just the right font and not just depend on a plain, 
generic font for all instances on a page.

Forcing web site owners who wish to show some design creativity to post Mac and PC 
versions of fonts that then must be downloaded and installed before someone can view a 
page seems regressive and pointless. It certainly makes web browsing a big pain. This 
especially hits third-world users who read lesser-used languages and who are otherwise 
stuck with a single generic Unicode font provided by Microsoft -- a font that might not be 
exactly right foe the task at hand.

Better to provide more tools than fewer tools, in this case at least.

I'm confused; who are you arguing with? Everyone agrees that we should implement
this, don't they?
Walt (and perhaps others),

If NY Times offered to recommend the Mozilla browser on its site if it supported
font downloading, that would provide an incentive for someone to build it.

At present, there are a lot of people whining about the lack of dynamic font
support (me included), but no one so far has offered to either a) do it, or b)
pay for it.

I would imagine that font companies would have a financial incentive to support
downloadable fonts, because it would increase the number of purchased fonts, but
so far none have come forth.  Is anyone from Bitstream or another font company
on this list?  If not, and you know an influential person at one of these
companies, perhaps you, gentle reader, can forward this to see if there is
interest in either building or paying for dynamic font support.

We've all seen it's not enough to complain.  This bug is several years old.  We
need to find someone who gain money or fame from supporting this work, and ask
them to support it.
(In reply to comment #57)
> > Find me one Bengali site that doesn't use either dynamic fonts or pdf files
> 
> Sure, here's one:
> 
>
<http://www.stat.wisc.edu/~deepayan/Bengali/WebPage/Archive/Madhusudan/Chaturdashpadi/archive.bn.html>

Well, I see a lot of question marks in the Bengali version.  Am I supposed to
install (support for) Bengali fonts on my system (if there are some for it) to
see how Bengali looks like?  Unicode is merely an encoding.  You need proper
fonts to benefit from it.  So IMHO that there is Unicode is a null argument
against dynamic fonts.

BTW: I use .EOTs and .PFRs at my site with Valid CSS2 and would be very happy to
see this working in my favorite web browsers, Mozilla/5.0 Navigator and Firefox
as well.  Voted for this bug.


PointedEars
*** Bug 208603 has been marked as a duplicate of this bug. ***
This is a little silly.  Everyone seems to agree that dynamic fonts would be a
Good Thing to have.  Even if they aren't, observed facts indicate that they are
in common use and people want them (including website designers who just want a
little better control over their typesetting).  They are a feature which argues
in favor of MSIE, and whether or not the people arguing for it are right or
wrong, lacking it puts Mozilla at a disadvantage.

This bug should probably be bumped in priority.  With Freetype and other
font-rendering engines improving, it should be possible to accomplish this.

(It would be a lot more convincing if I could say I was going to work on it, but
that remains to be seen)
Priority is up to the developer working on it, which is none. Care to take it or
find someone?
*** Bug 261314 has been marked as a duplicate of this bug. ***
Mozilla does not support dynamic fonts
Hi Folks,

This is the *only* issue due to which i
still need to fire up IE. I know of at least a couple
of people who are in the same boat as me.

Dynamic fonts worked just fine with Netscape4.x,
surely that code is lying around somewhere?

I noticed someone said "Find someone or pay for it",
well, i would be willing to donate something to a
paypal account if someone picks this up.
Or, if you are in Bay Area, California, call-me up
for a couple of cocktails followed by a nice 5 course dinner
costing, say 200 bucks, in a place of your choice? [If you
prefer cash, just come on by...]

Does it sound like i am desparate? Yes i am. I hate IE.
-ashu


I'd throw in another $200 for someone to add font downloading.
I would give this a crack, but I haven't done any Mozilla related development
before.

Anybody got an idea where in the source to begin looking?
One should browse around the bugs... the issue is simply that NS4 was linked to code of BitStream 
which was downloaded as part of NS4... so there's no real code to reuse down here.

So there's an amount of lobbying to be done, aside of plain code rehaul!

paul
Not necessarily.  Going the BitStream route probably isn't the best way to go
anyway: BitStream's PFRs were proprietary.  Mozilla should be able to use
TrueType/PostScript fonts dynamically, as well as some ultra-compressed PFR-like
format, if necessary.  PFRs themselves would be good, too, for compatibility,
but shouldn't be the only option.

> Additional Comment #82 From Paul Libbrecht  2004-10-18 15:27 PDT  

> One should browse around the bugs... the issue is simply that NS4 was 
> linked to code of BitStream which was downloaded as part of NS4... so 
> there's no real code to reuse down here.

> So there's an amount of lobbying to be done, aside of plain code rehaul!

> paul
Kurtis: Even if a seasoned Mozilla developer isn't going to work on this, you
can probably get some pointers on where to look through newsgroups, etc. I also
suggest you look at other CSS2, and font patches in bugs and find where in the
source you can look for reference.
Okay, just in poking around yesterday in the freshly-downloaded code, it is
pretty obvious that something like this needs to be done per platform, since all
the font managers obviously handle fonts differently - handing off the fonts to
the system for rendering according to the platform specific font supporting
mechanism.

I confess that, in general, I'm a really busy guy (aren't we all) and so people
probably shouldn't expect me to fix this problem. This will probably turn out to
be more of a learning exercise than anything else.  I'll keep looking at it, but
it will take some time to figure out the platform specificness.  I also know
this bug report isn't the place to discuss day to day workings of writing the
patch, so just assume for now that I'm not working on a patch, and then you'll
all be plesantly surprised if I come up with one.
Best of luck Kurtis.

I really hope that some seasoned Mozilla developers
would help with some advice on the best way to proceed
and with some guidance to Kurtis on where to look.

I also hope that more people who have voted for this bug
would also vote with their wallets (even if it is
10-20 bucks, it all adds up).

And to re-iterate, my offer was neither in haste nor in jest,
it is a genunine offer which stands.

-ashu

I'm willing to kick in something if it becomes official.  But I don't believe a
few hundred bucks is really the answer.  Some of those folks who work for major
companies who are waiting for dynamic fonts need to get those companies to make
a sizeable donation to the Mozilla Foundation and let them find a developer to
do the work.
*** Bug 272200 has been marked as a duplicate of this bug. ***
Hey, due to personal events in my life, I'm gonna be unable to work on this bug
for the forseeable future (at least into next year) so if anybody else is
interested, they should pick this up.

When I dropped by the Mozilla dev channel, the guys weren't as helpful as they
could've been.  In fact, the guy who gave me the most information made it sound
like the change should be fairly easy for him, but he just didn't have time to
do it and when I was asking him questions kept responding just with "no, do it
this way" instead of explaining to me what was going on.

That said, it doesn't look impossible, but it does seem to involve interaction
between a couple of different parts of the Mozilla source, so a developer
knowledgeable about the Mozilla architecture is probably a better fit for this
than me.  If this is still open next year, I may look at it again.
> In fact, the guy who gave me the most information made it sound
> like the change should be fairly easy for him

Yeah, a lot of these bug fixes are easy conceptually for the strong hackers, but
still would be very time-consuming. The sad thing is that instead of documenting
what needs to be done for other people to make patches, they often don't give
any useful information in bugs and they sit unfixed when they could be fixed by
someone less familiar with the code if there were information given.

See bug 114760 -- Bugs not planning to be worked on need to be clarified for
other developers

I'm going to paste some of your comment in that bug.
Bummer. Maybe we have to find another way.
Anyone in the interest list a CS student who can perhaps pick this up
as part of a project or something?

Just throwing ideas around...
*** Bug 274246 has been marked as a duplicate of this bug. ***
*** Bug 274287 has been marked as a duplicate of this bug. ***
*** Bug 275295 has been marked as a duplicate of this bug. ***
*** Bug 282991 has been marked as a duplicate of this bug. ***
*** Bug 284735 has been marked as a duplicate of this bug. ***
*** Bug 288577 has been marked as a duplicate of this bug. ***
*** Bug 288575 has been marked as a duplicate of this bug. ***
*** Bug 289879 has been marked as a duplicate of this bug. ***
*** Bug 291928 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
No longer blocks: majorbugs
*** Bug 297864 has been marked as a duplicate of this bug. ***
*** Bug 302365 has been marked as a duplicate of this bug. ***
*** Bug 304984 has been marked as a duplicate of this bug. ***
In http://www.svgopen.org/2005/papers/MozillaSVG/#S6.1 , it's stated that Full
SVG 1.1, including SVG defined fonts, is planned for Mozilla Firefox 2.0.  I
wonder if this somehow means that we'll have WebFonts as side affect, or at
least will be one step further for implementing CSS3 WebFonts.
*** Bug 312981 has been marked as a duplicate of this bug. ***
*** Bug 315628 has been marked as a duplicate of this bug. ***
*** Bug 315629 has been marked as a duplicate of this bug. ***
*** Bug 317537 has been marked as a duplicate of this bug. ***
I know I've beaten this point to death, but... I wish that the bugs being filed about Indian web sites with incorrect character encoding that depend on font embedding would not get marked as duplicates of this bug. That's not the point of font embedding, and marking them as duplicates against this gives that false impression. This is a *design* enhancement request.
(In reply to comment #109)
> I know I've beaten this point to death, but... I wish that the bugs being filed
> about Indian web sites with incorrect character encoding that depend on font
> embedding would not get marked as duplicates of this bug. That's not the point
> of font embedding, and marking them as duplicates against this gives that false
> impression. This is a *design* enhancement request.

I won't do it again.
It would be good if they're duplicates of something, though, since it may be useful to know how many such bugs we're getting.
With 5+ years open, this must be the oldest unresolved bug in the database. Firefox 1.5 is targeting CSS 3.0 and still unable to render dynamic fonts?

Would some authority please mark this as "will never happen as nobody is interested to solve it, despite it is part of CSS2" so we no longer wait for it. Then we can tell our customers to use IExx and end this discussions for all time.
(In reply to comment #112)
> With 5+ years open, this must be the oldest unresolved bug in the database.

Nope. Bug 9942 wins hands down (actually by 14 months).

Have a good Thanksgiving!
Actually I've checked that the oldest surviving beast on the database is bug 350 opened on 1998-05-14 01:20 PST. So do not bother us with such freshies as this little problem, young man.

Sorry for the spam.
I have to repeatedly swith to IE because of this issue. Many non-english websites use dynamic fonts, and for that reason, that huge community can never use Firefox. Many people, like my wife, will never switch to Firefox because of this issue.
(In reply to comment #115)
> I have to repeatedly swith to IE because of this issue. Many non-english
> websites use dynamic fonts, and for that reason, that huge community can never
> use Firefox. Many people, like my wife, will never switch to Firefox because of
> this issue.
> 

That's very very true. It's been a big annoynace for me for years. Either people don't switch or - like me - can't read some newspapers I love to read because I don't (want to) work on Windows. And somehow I find it surprising why this doesn't move up in priority given there is a lot of potential to get more people to use mozilla-based browsers just by implementing this. I know at least 10 people in my own immediate friend's circle, and my wife - who would do that.
Try using the FF/TB extension Padma (https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&id=873) as a partial solution to this problem.
Is there a similar add-on for Bengali ?

(In reply to comment #117)
> Try using the FF/TB extension Padma
> (https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&id=873)
> as a partial solution to this problem.
> 
Do these extensions include code that can be used to add support for dynamic fonts, or do they just detect that a dynamic font has been used, and adjust the characters from the page to the appropriate range in already installed Unicode fonts (which means they do not actually use any dynamic fonts)?
*** Bug 330250 has been marked as a duplicate of this bug. ***
*** Bug 344645 has been marked as a duplicate of this bug. ***
*** Bug 360910 has been marked as a duplicate of this bug. ***
Owm... OK

1. This is not an internationalization bug.  All you bengalis please demand that Web pages are written correctly.  It's your problem.
2. This should not be very hard to implement.  We have Pango rendering now.  See http://developer.gnome.org/doc/API/2.0/pango/index.html and start from there.
3. This is also a practical problem. Right now there are n number of sites that rely on this feature, that don't currently work in Gecko based browsers. To say they should write to the standards or fix their own sites is a good suggestion, but it doesn't solve the problem as much as it just points to the cause, and it's easier said than done.

4. This feature has more use than just to get those sites to work in Gecko based browser. With all the talk these days about RIAs it'd be nice to finally get first rate font support in html (well, to re-get it, since it existed in the 4.0 days). Making dozens of header graphics, or using Flash/JavaScript based work-a-rounds is really getting old. Gecko has had support for JavaScript, DOM, HTML, SVG, XML, XHTML, CSS, various image formats etc., all so you can have a richer web based experience, but it still doesn't support embedded fonts, after all these years.

I understand that the people who could implement this feature are busy with other, probably more important things, and I'm willing to wait for someone to fix this, since I don't have the knowledge or time to do it myself. So please don't get me wrong. I do think it's time to move this up on the list of priorities though. (Just my two cents)
I wish to add that font availability is another weak point that we all experience with mathematical documents on the web: no author can be sure that a given character will be rendered. I would expect downloadable fonts to solve most of these problems in a way that is still clean (for the html code) and accessible, as opposed to any server-side-rendering.

And as far as I know there is no way in javascript or CSS to know about the availability of a glyph in any font (you can select based on unicode ranges availability in CSS but that's way too coarse, e.g., no font implements the full math unicode range!).
May I remind the developers on chapter 15 of the CSS2 definition (from 1998!) which clearly defines how fonts are to be handled, with a long paragraph on font sources and file formats.

http://www.w3.org/TR/REC-CSS2/fonts.html#referencing

My I remind further that the SVG specifications do make use of "loadable fonts" too:

http://www.w3.org/TR/SVG/fonts.html

Mozilla is proud to comply to both of these specifications, as long nobody talks about the font issue. It's some kind of "family secret", hidden deep in the dungeons. A nasty daemon that raises it's head after each and every new release and that is kept quiet by stubborn ignoring.

It looks as if the Mozilla development team has order to keep their fingers off any font issues and to focus the work on cosmetic enhancements instead of implementing missing parts of the specifications.

Now that we have FF 2.0, there is again some moaning about this, that will eventually die out as usual after a few weeks.

The developers do magic every day in different parts of the program. All specifications are published and OpenType is free to use, so copyright is not a problem here. I cannot believe it's out of their capability to make a public accessible font file available to the operating system.

Luckily, since M$ has just released it's new IE7, which is a vast improvement over 6.0 and which got almost every CSS problem fixed, there is a true alternative now. At least for all of the Windows users.
<snip>We have Pango rendering now. <snip> 


Now that's called passing the buck. Pango (as of today) can't even render *unicode Indic fonts* decently. Refer: https://bugzilla.mozilla.org/show_bug.cgi?id=356049


Well, as the saying goes, if you can't be part of a solution to a problem, atleast  you can be at your best in making it more complex. 
What I meant about having Pango now is that Pango can interpret font data, and together with fontconfig or the "other OS's" native font technology it's now feasible to download a TTF (and, in Linux, Adobe Type 1) font referred to by  @font-face{ ... }
*** Bug 361622 has been marked as a duplicate of this bug. ***
*** Bug 361622 has been marked as a duplicate of this bug. ***
The provided URL, http://www.malayalamanorama.com , is very difficult, if not, impossible to understand from a web standards and from a web author point of view. First, it uses no doctype declaration, has over 460 validation markup errors (and that is in transitional DTD, not strict DTD), abuses javascript, flash, blinking stuff, advertisements, overconstrained tables, over-excessively defined markup code, over-excessively constrained markup code, over-declared markup code, tons of <br>, &nbsp;, spacer.gif, etc, etc, etc... 

The webpage is declared to be written in English - not in Malayalam -
line 45: <html lang="en"> 
line 66: <META content="en-gb" name="language">
it's to be served as iso-latin1 on top of that
line 69: <META http-equiv="content-type" content="text/html; charset=ISO-8859-1" >
and to use the Manorama font and no other proposed font. The thing with Manorama font is that it is not an Unicode font: all Malayalam glyphs are occupying latin-basic positions and not their respective assigned positions in Unicode. So, this is a major serious flaw with the design of the webpage. 

You see, I had myself already a true Unicode font for Malayalam language (Kartika.ttf) and it was installed many years ago. The web author of that site is making many mistakes, serious ones.
For Western languages (languages covered by iso-8859-1), I only choose fonts that are capable of rendering western languages, and definitely not Malayalam language. The web author goes against such logic; the web author goes against very reasonable, coherent and rational assumptions for both the browser users and for browser vendors/manufacturers.
If the web author had defined in this manner 

<html lang="ml"> 
<META content="ml" name="language">
<META http-equiv="content-type" content="text/html; charset=utf-8">

his webpage, then I would have been able to see the correct Malayalam glyphs even if he had also declared
body {font-family: serif;}
because, in my settings, I have a default serif font for utf-8.

The browser detect and forking code at
http://static.manoramaonline.com/portal/manoramafont/cpy_bvfont.js
is also extremely questionable, poor and bound to be wrong most of the time. Very few versions of Netscape support pfr. Not all non-Netscape browsers support .eot, only MSIE5+.

-----------------

The purpose of dynamic fonts is not to support international charsets and should not be used to support international charsets. 
"supporting international character sets via font embedding is an 
awful practice that needs to be stopped."
"This is not an internationalization bug." 
Agreed.

Removing intl keyword
Keywords: intl
(In reply to comment #57)
> > Find me one Bengali site that doesn't use either dynamic fonts or pdf files
> 
> Sure, here's one:
> 
> <http://www.stat.wisc.edu/~deepayan/Bengali/WebPage/Archive/Madhusudan/Chaturdashpadi/archive.bn.html>

I went to that site. The webpage is encoded as utf-8 but the webserver serves it as iso-8859-1: this mismatch causes problems on the users application browser. 

Web sniffer to access the HTTP response headers will indicate that the server reads the document as iso-8859-1 and not as utf-8 and so the character encoding mismatch is easy to see:
http://web-sniffer.net/?url=http%3A%2F%2Fwww.stat.wisc.edu%2F%7Edeepayan%2FBengali%2FWebPage%2FArchive%2FMadhusudan%2FChaturdashpadi%2Farchive.bn.html&submit=Submit&http=1.1&gzip=yes&type=GET

The character encoding mismatch is reported by the W3C validator:
http://validator.w3.org/check?uri=http://www.stat.wisc.edu/~deepayan/Bengali/WebPage/Archive/Madhusudan/Chaturdashpadi/archive.bn.html
(99 errors with transitional DTD)

This character encoding issue (the web server is MISconfigured) is rather easy to fix and is covered by several documents.
(In reply to comment #133)
> The provided URL, http://www.malayalamanorama.com , is very difficult, if not,
> impossible to understand from a web standards and from a web author point of
> view. First, it uses no doctype declaration, has over 460 validation markup
> errors (and that is in transitional DTD, not strict DTD), abuses javascript,
> flash, blinking stuff, advertisements, overconstrained tables, over-excessively
> defined markup code, over-excessively constrained markup code, over-declared
> markup code, tons of <br>, &nbsp;, spacer.gif, etc, etc, etc... 

That doesn't have anything to do with this bug report.  The rest of the comment is relevant but is repeating what was already said in comment 38.

There is consensus that using dynamic fonts is the wrong way to build international language Web sites -- using the correct Unicode characters is far superior.  But the facts remain that (1) many sites do use dynamic fonts for this purpose, and (2) that there are other valid uses of dynamic fonts desired by authors.

Either way, at this point this bug report has so many comments that anything written here is unlikely to influence any eventual implementation of dynamic fonts since whoever does the implementation is unlikely to find the comment.  Things that require *discussion* should generally take place in newsgroups / mailing lists, not bug reports.

Developers have discussed implementing dynamic fonts a number of times recently, but not in this bug.  The problem is that there are basically two approaches, both of which are quite difficult:
 (1) getting the system to select and render the font, which requires inserting a font into the system's font selection mechanism in a way that applies only to one page and not to any others
 (2) selecting and rendering the font ourselves, which means that we have to stop using the system's font selection mechanism and do it ourselves in order to interleave system fonts with dynamically provided fonts.

Both of these require significant amounts of code.
I do not agree that "using dynamic fonts is wrong for internationalization purposes". What's wrong is only "using wrong encodings" as seems to be described in the usage of the web-page above.

This does not remove the need for dynamic fonts for me, for example, to display most fancy characters, even properly encoded: my machine can display some chinese but I am convinced it is missing an amount of other glyphs.

And I do know that it is missing most glyphs of the math unicode tables and most probably of the symbol ones... both purposes justify dynamic fonts, I believe, just as a better font-predictability. Remember... at the time, people we putting pictures instead!
I would like to share my findings about how dynamic fonts can be implemented in Gecko. All 3 platforms have ability to temporarily add TrueType or OpenType font that can be used only in the calling application and is not installed system-wide:

Windows: AddFontResourceEx <http://msdn2.microsoft.com/en-us/library/ms533937.aspx>

Linux: FcConfigAppFontAddFile <http://www.fontconfig.org/fontconfig-devel/r1988.html>

MacOSX: ATSFontActivateFromFileSpecification <http://developer.apple.com/documentation/Carbon/Reference/ATS/Reference/reference.html#//apple_ref/c/func/ATSFontActivateFromFileSpecification>

Gecko must handle cases when different pages use different downloaded fonts that have same names. I think that downloaded font files should always be changed by Gecko so that names are unique (e.g. like "Gecko-4F2A5BBC") and CSS font names that use this downloaded font must internally be renamed to the unique name. This will add code for changing font name in font file but I think it won't be much code because it's for such specific purpose.

I guess part of such implementation will be in cairo project.

I would like to see comments from more knowledgable people if the above may work or there are flaws about it.
The main issues I can think of at first glance are:
 * those APIs may not be designed for untrusted fonts and thus may have security bugs when handling malformed font files

 * the set of font formats that we want to support should be the same across platforms (though we could handle that by restricting what we pass to those APIs to fonts that we've checked ourselves are cross-platform formats)

The renaming hack seems like it could work, although it's really a workaround for the lack of font selection contexts to which fonts could be added.  (However, would that really work?  Is the name always an argument to the function rather than something contained *inside* the font?)
The other issue with the renaming hack is that (even if it doesn't affect other apps), there are cases where *we* search through all remaining fonts to find a font with a particular character; we don't want to use fonts provided by other Web pages (since the behavior is then nondeterministic, and the fonts may be hacks that provide incorrect glyphs).
So basically there are (at least) 4 different tasks to get this working:

1. Do platform work to utilize each of these three different APIs to get the fonts to load for Mozilla app only (not system wide).

2. Figure out how to validate Fonts to avoid possible malformed font attacks (if the system methods don't do that already). Could FreeType be used to parse and validate font formats (even if it's not used to actually draw the fonts)?

3. Find every function that deals with system fonts and font lists, and make them ignore the temporarily renamed page specific fonts. If there is an interface for that (I'm not familiar with the code base), that'd be great, cause you'd just have to modify that. Otherwise, maybe it's a good idea to build that interface and make the rest of the code base use that.

4. Make sure we only allow cross platform fonts - .ttf (both TrueType and OpenType) seem to be the most compatible, maybe .otf (CFF PostScript glyphs in OpenType package) are also compatible (though in .NET at least, they were not compatible to use in private font lists until v3.0 - I don't know if that was a .NET or an underlying platform problem).

I'd also add:

5. Before any of the private font installation stuff starts, Mozilla should check the embed bit in the fonts, to see if embedding is allowed, and abort if not.

6. Could FreeType be used to convert non-system font formats like .eot or adobe .cff (embedded by Illustrator in some SVG fonts) to a compatible font (like .otf) to be installed for Mozilla as described above (it might be worth it to check with the font forge people on that)?

7. Would any of this help with SVG glyphs, or could a ground up SVG glyphs implementation be used instead of this whole idea? In this model, you'd have to use a tool (like Adobe Illustrator) to convert the fonts to SVG glyphs, and embed that instead of the actual font file(s).
From comment 133:

"The purpose of dynamic fonts is not to support international charsets and
should not be used to support international charsets."

Then what technology should be used to support those international charsets for which the operating system does not supply a font? And what technology should be used to support those international charsets that were not encoded in Unicode at the time the operating system was released? GIFs?

Which mailing list or newsgroup would be most appropriate for questions like this?


From comment 140:

"Could FreeType be used to parse and validate font formats (even if it's not used to actually draw the fonts)?"

Maybe not.  TrueType fonts may contain hint programs that modify glyphs before they are rasterized.  Microsoft and Apple implementations use these hint programs.  FreeType's default configuration ignores hint programs and will do so for several more years until Apple's patents on hint programs run out.
Have anyone considered drawing WebFonts with cairo instead of using system font API? cairo 1.6 has user font API in their ROADMAP <http://gitweb.freedesktop.org/?p=cairo.git;a=blob;h=2eb28f48088c78ddb8dc8e9498f318dc4a4a1937;hb=9da86e4a386505288c3a933f30583abf7706c950;f=ROADMAP#l64> and it seems it's relevant to SVG fonts <http://weblogs.mozillazine.org/tor/archives/2007/04/smil_animation_and_svg_fonts.html>.  But I'm not sure if it's better path than using system font API - @font-face is much more important for non-latin languages and many of them (Indic, Arabic, ...) use features beyond simple character code -> glyph mapping. I'm not sure if SVG font ligatures will be enough.

Is this reasoning (that not using system font API limits WebFonts usefulness too much) correct?
This Bug has a7 years old, isn't it time to fix it, my bug report (396195) was marked has duplicate because i worked the way arround it with the letters in IE with .eot and in other browsers with flash but with flash is very complicated and unrealyable cause i loose the button effect on Browser and the links are lost has well. It's been marked to be solved in the future and the future is now.
Please feedback has soon has possible!
Blocks: 407316
IMO The best way to fix this would be to add support for CSS 3 @fontface 
see bug: 70132

I must agree.  Mozilla products are promoted as compliant with W3C specifications.  Thus, the implementation of dynamic fonts should comply with W3C's "Web Fonts" module of CSS3.  

Before implementing @font-face, however, it would be best if the "Web Fonts" specification were brought closer to a final version; it's currently a working draft that hasn't been updated in six years.  This is a W3C issue beyond the authority of Mozilla, but the Mozilla Foundation is a W3C member and should be able to push for progress on this specification.  
(In reply to comment #147)

> Before implementing @font-face, however, it would be best if the "Web Fonts"
> specification were brought closer to a final version; it's currently a working
> draft that hasn't been updated in six years.  This is a W3C issue beyond the
> authority of Mozilla, but the Mozilla Foundation is a W3C member and should be
> able to push for progress on this specification.  

Work on a new draft of the CSS3 Fonts spec, one that simplifies the definition of @font-face and is closer to what Safari, Prince, Opera and Mozilla implement or plan to implement, is already underway:

  http://dev.w3.org/csswg/css3-fonts

Once the rewriting has been completed and the CSS WG has a chance to discuss issues related to this, I'll switch over the CSS3 Fonts and CSS3 Web Fonts URL's to point to the new working draft.  I'm sure there will be general discussions of this on the public www-style mailing list.

The @font-face implementation Gecko is tracked via bug 70132 and its dependent bugs.

I've added a new bug, bug 444571, relating to the distribution of what for a better term might be called "Free Software core fonts". Whilst only tangentially related to this bug, the proposal addresses some of the same issues discussed here, such as support for Indic languages.
@font-face {
 font-family: "manorama";
 src: url("http://www.manoramaonline.com/mmfont/Manorama.ttf");
}

works just fine for me on the original page submitted for an example...  I don't see a problem with the original bug in current Firefox
This bug has finally been fixed with Firefox 3.6 (Gecko 1.9.2) 
I opt that it may be closed.
Wow, neat, forgot this was lurking.  @font-face support shipped with 3.5, closing this.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.