How Scribd's HTML document reader works (part 1)
coding.scribd.com
coding.scribd.com
One of my favorite features is pressing 'q' causes it to quit, solely because I can quickly (It's blazing fast, at least on Linux) open up a pdf, pageup/pagedown through it, and quit the application quickly, efficiently and easily.
So it's not built with the most attractive toolkit, but it does seem to meet your requirements, no? (Okular is close to converting me from xpdf, but it's those extra several milliseconds during startup and the lack of a single key to quit the app that keeps me with from switching.)
I love its minimal GUI interface (by default, C-m for toggling menu visibility!), highly customizable navigation panel, and its 'trim margins' view option. I also find it faster than xpdf after startup. The only thing that i don't like right now is the slow chm rendering.
I'd talked to a few font foundries in the past, and very few would let me use their fonts with a @font-face (or, in their eyes, distribute their fonts indiscriminately).
Only the actual font file can be copyrighted. Not the shape of the font. So all you have to do is convert them to some other format.
Even creating derivatives of fonts is often restricted, eg, the Adobe Font Folio EULA considers derivatives under the same license as full fonts and the Linotype EULA states "It must be ensured that the Font Software cannot be fully or partially extracted from said documents" (emphasis mine). So, presumably, it would be potentially problematic even if you are extracting individual characters and generating new fonts.
As I understand it, since fonts can't be copyrighted it's purely a software licensing & "piracy" issue. If you've figured out a way we can all get around that it would be a big deal. Maybe you are in a unique situation because you aren't agreeing to an EULA and, instead, simply extracting characters from fonts embedded in documents uploaded by your users. Hopefully you'll share the details of how your attorneys have advised you about what a website's liability is in this area using different techniques
Honestly, on one hand I'm hesitant to comment about it and give a voice or any encouragement to the foundries, but on the other hand it would be pretty shitty if scribd just skirts these issues and plays fast and loose with the situation while the rest of the web is still stuck using the same old font stacks because they can't afford to risk the legal fees.
Fonts can't be copyrighted. They didn't agree to any EULA. All they need to do is convert the font to some other format, and they are legal.
And BTW, this line is ridiculous: "It must be ensured that the Font Software cannot be fully or partially extracted from said documents".
It's possible to embed a subset of the characters, and that's what most require. But to prohibit even a subset? That means you can not use the fonts for any electronic documents whatsoever unless you convert them to bitmaps, which means they are almost useless for PDFs.
I personally would never buy a font with such a restriction unless all I made was print.
BTW, if you want to be legal, just download (pirate) the font file, and convert it to some other format. You never agreed to a EULA, and fonts can't be copyrighted (only the original file can be).
In theory they could complain about the original pirate act, but they would have zero evidence, and any subsequent usage is legal.
The shapes of the glyphs are not protectable. The font file is considered to be a computer program, and is protectable as such. Converting it to a different format doesn't get around copyright any more than compiling a C program does.
I don't know the actual extent to which copyright protection covers font software or derivatives. There is at least some related case law, but I've only skimmed it and am not an attorney.
That means you can not use the fonts for any electronic
documents whatsoever unless you convert them to bitmaps,
which means they are almost useless for PDFs.
They could start crawling the web today for PDFs that embed fonts infringingly, but they aren't very sophisticated, and even they aren't that stupid.
The situation on the ground isn't going to change from the way its been for the last 25 years -- normal people are going to continue to use whatever fonts, obtained however, and distributed wherever, to whomever, whenever. %90 of font choices made made will continue to be crap.
Besides, text selection wouldn't work.
Have y'all managed to avoid implementing a GDocs-style system for hiding text underneath bitmaps for selection?
I'm curious about the other issues you had as well.
"[...]we need to store three font files: One for Internet Explorer (.eot) one for embedded devices (.svg) and one for Firefox, Safari, Chrome et al (.ttf)."
Go IE!