Many years ago, long before the web existed or anyone other than the military or academia knew about the internet, I was still doing product manuals (see above). Working with the rather primitive DTP products of the late 80s to early 90s on PCs (yeah, yeah, I know…), it was a major hassle to place tiny graphics of screen icons or symbols as printed on keyboard keys within a line of text, so I came up with the idea of creating custom PostScript Type 1 fonts so it was just a keystroke and a font menu selection to make the character appear in the text at full PostScript resolution (like having a tiny high-res graphic as created in Adobe Illustrator).
This was a wonderful solution that the whole staff loved, and we used this solution for nearly 20 years. Other tech pubs shops within my company and at our competitors saw the same advantages I did and began doing the same thing themselves.
Than came the web, and over time, everything changed. We switched to Adobe FrameMaker for our page layout program, and after a brief period of Mac usage, we were forced back into Windowsland. We did OK for a few more years, but then about four or five years ago, we began hearing wispy conversations from our superiors and folks in the Marketing organization about converting our manuals to HTML. We were able to blow them off for a few more years, but late last year, we could blow them off no more. We looked at a lot of potential solutions, but at least temporarily, we (to be more accurate, I) began using Adobe FrameMaker’s save-as-HTML function. The output was ugly as sin, required 10-20 hours of cleanup before we shipped the files off to an outside vendor who would convert our beautifully-crafted custom fonts to JPEG bitmapped graphics format. They would then pore through the HTML code and find every place our custom fonts (often characters from three or four fonts were used) were placed, remove the HTML code that called up the character in font form, and replace with HTML code for inline graphics (such as ““).
Why do this (and pay people a lot of money to do this laborious work)? Simple, unless you have our entire custom font library of some 200 fonts installed on your personal computer (Mac or PC), you will not be able to see all those beautiful inline graphics rendered from fonts, because fonts and HTML really don’t get along together, unless you are talking about Arial, Times, Courier, etc.). So we have to pay someone over a thousand dollars per book to do this grunt work. Then the files come back to me, where I go through the package, HTML file by HTML file, and fix any errors directly in the HTML code. This is another 10-20 hours of work. then and only then can we send the files to our graphic design team to tweak them for “branding” purposes.
All of that said, why isn’t there an application out there that can intercept text and convert predetermined fonts from one of the popular vector formats into individual inline JPEG graphics files during the process of converting a text file into HTML? I can’t believe my shop is the only one that is having this problem. You’d think the Adobe Type Manager technology built into Adobe Acrobat, which already generates bitmaps for the screen, could be intercepted and converted into something, but, sorry Charlie…
I have been talking to various companies/consultants who think they can do the job, but the process itself is going to be murderous. First, we will need to build a library of every single character in each and every custom font, name each character in some consistent fashion, place these characters in a carefully-crafted directory structure, and then use some kind of “transformation engine” to analyze the FrameMaker or XML file, find out where all the custom font characters are being used, remove the HTML coding for the custom font and insert HTML coding for an inline graphic. I won’t tell you how much money we are being asked for by several potential suppliers, who still aren’t even sure if they can do it.
Does someone have a better idea? Oh, by the way, PDFs are not an option. We have been doing PDF versions of our manuals ever since Acrobat 1.0 came out somewhere around 1992. Senior management and some of our customers are saying PDF is “too hard” and HTML is the way to go. Also, the option of reverting to using inline vector (EPS) graphic files is out–the boss says it’s too hard for our authors. That option would actually be the easiest solution to the FrameMaker to HTML problem with a product that would do it “out-of-the-box”, but, like I said, it would add a huge burden to the writing team. Flash is no good because of the huge development effort required, and supporting that work in multiple languages is a similar nightmare.
Welcome to my world… Sigh.
Leave a Reply
You must be logged in to post a comment.