You have no clue what you are talking about. First, there is no reason that a font installed on your computer needs to be uploaded to a server for you to be able to use it in web applications provided by said server. Second, desktop font licenses are not multiuser server licenses. If a service vendors wants to license a font for use on a server with web applications then they are free to do so; this does not give you the right to install fonts you licensed for desktop use on servers. Third, this has absolutely nothing to do with a monopoly. You do not know what a monopoly is and need to go back and study monopolies and antitrust before you throw that word around again.

I don't think embedding the fonts in the text is practical or even desirable. Fonts should be linked the same way images should be linked. Otherwise you have an insurmountable barrier: rebuilding the web to allow fonts binaries to be embedded with text on all web forums and web-mail apps.

Warning: I'm not involved in technical aspects of font embedding. What follows is pure fantasy.

Hosted fonts (like Typekit) could allow for "anywhere" use. If you used the font on a web forum, unique code (maybe inline CSS?) could be included which links to the hosted font so it appears to all users. This code would be sent to the font host and it would correlate with the users's account. How do you prevent someone else from using the CSS to write their own messages other other web forums using the same font? A unique code would be generated for each instance. The code would be based on the words in the text itself (like a CRC check). Maybe a browser extension could take care of the details so the user wouldn't have to deal with the technical aspects. If the user is logged into their "font account", they could generate the proper code which would allow then to use the font they paid for. Other users could copy/paste the text and the fonts would still show up. If the text is modified, the CRC check fails and the font won't display. This would allow you to buy a font license, use the font in webmail, on forums etc.

Of course, every site you use the fonts on would have to allow this type of code to be included. Browsers would have to be allow this type of use and users would have to upgrade their browsers. "Implemented immediately" is impossible.

Monopoly doesn't apply to this situation. There's no big font company in charge of font embedding that's preventing this. Font embedding is the result of lots of individuals, organizations and companies innovating and trying to get fonts on the web. Browsers makers are slow to improve but that's not a monopoly either.

@javascript: In another thread, you have said "I expressed / proposed clean non-dirty law abiding development without any font piracy", but in that case, it's unclear what the point of your posting in this thread is.

Of course DRM creates problems for law-abiding users of fonts, music, or whatever. But it's there in order to prevent piracy. So to just say that it should be done away with, to condemn it as bad, as monopolistic, without addressing the issue of piracy - even if to note that piracy from websites using fonts is not a real threat at present, because there are other wider avenues for piracy - creates the impression that one is, at the least, indifferent to piracy.

When it comes to uploading fonts to "member participation websites", there's another obvious issue. Just because you would be uploading fonts which are legitimate doesn't mean that someone else, unaware of copyright, wouldn't upload a font which is copyrighted... and create liability issues for the website operator.

Preventing losing money to piracy, preventing getting in trouble from being blamed for the piracy of others - these things are the top priorities. It doesn't make sense to complain about that; of course the world revolves around money a little bit too much, but money is the means of survival, so what else can you possibly expect?

The foundries aren't monopolies. As often as I flip Apple and Microsoft the bird, they aren't monopolies either. There is always BSD and Linux.

Now imagine that only one company can legally make/import road vehicles. Or typefaces/fonts. Or operating systems. That would constitute a monopoly.

@ray - it always sounds so techy when people say 'binaries' - like they are speaking about some mystical thing i will never comprehend :-)

Well, the word "binaries" is a technical term. It means files like the ones on your computer that end in .EXE or .COM for computer programs. You can run the programs, but you can't read them; the files contain the actual pattern of bits that will be placed in the computer's memory - possibly with instructions for relocation or linkage. (Actually, files like that are more likely to end in .OBJ, and for arcane technical reasons, while other computers had operating systems that did relocation and linkage when you ran a program, MS-DOS and Windows do without this flexibility, using other methods to link programs to external libraries.)

The other kind of file that isn't a binary file is a "text" file. In the case of a program, that would be the source code - written in C, Pascal, BASIC, Assembler, or some other programming language.

So the "binary" is the final product - the program, or the font, all wrapped-up and ready for use... but not intended to be modified by the end-user. (In the case of fonts, though, while .TTF files are binary, they are what font editors work on; a font editor may have its own file format too, but there really isn't a "source code" format for fonts.)

Actually, M$Windows does do run-time linkage - that's what the DLLs (Dynamic Link Libraries) are for - much like the shared objects (.so) on Unix/Linux systems.

I think that Knuth's Metafont was the only font format with canonical source code. All others seem to be or have been interpreted BLOBs. (Binary Large OBject or B* Lump Of Binary). Mind, FontForge's data files (.sfd) are text, and thus 'easy' to hack.

At this moment, I think it's time to point people at The Hacker's Dictionary aka The Jargon File.

@Té Rowan:
Actually, M$Windows does do run-time linkage - that's what the DLLs (Dynamic Link Libraries) are for - much like the shared objects (.so) on Unix/Linux systems.

Yes, I am aware of that. But they don't do it the way some old mainframe systems did it: reading in a directive in the .EXE file which says to replace certain addresses in the machine code it contains with the memory addresses of entry points in the external library (which would have to have been loaded into memory first).

Instead, a very different mechanism is used which requires the program in the .EXE to take care of setting up the links itself during its own execution.

quadibloc: Of course DRM creates problems for law-abiding users of fonts, music, or whatever.

There is no DRM, per se, for web fonts. Digital Rights Management involves technical mechanisms to restrict use of digital content, e.g. to a particular user, with stiff legal penalties in some jurisdictions for circumventing such mechanisms. The minor protections available to fonts on the web do not constitute DRM; indeed, the majority of browser makers made it very clear that they were not willing to consider DRM for fonts. Fonts are protected by legal licensing terms, not by technical mechanisms.

I had thought that one browser maker, Microsoft, supported its own web font format which at least provides an option of turning on a feature that ties the font to a particular web site, and that this qualifies as DRM for fonts.

But as no other browser supports that web font format, anyone who wants their site to display with the font on Firefox and Safari and Chrome indeed would have to make the font available without that protection.

The legacy EOT and PFR formats have an (optional) URL binding feature. In addition cross-domain linking restrictions can be applied at the server level for any file type. Some may claim that these are DRM, but its arguable. Are fonts embedded within PDFs DRM’ed just because they are tied to a specific document?

Well, you could rename the URL binding to Domain Restriction Mechanism... It might not be Digital Restrictions Management, but it would be DRM, then.

I don't consider URL binding as implemented in EOT to be DRM: there doesn't seem to be any legal obligation on the part of a browser to enforce such URL binding.