TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:RE: Symbol Font Considered Harmful From:"Andrew Warren" <awarren -at- synaptics -dot- com> To:"Fred Ridder" <docudoc -at- hotmail -dot- com>, <mike -at- writestarr -dot- com>, <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Fri, 3 Nov 2006 13:10:30 -0800
Fred Ridder wrote:
> the lower-case mu .... is character 181 (0xB5) in the
> ISO-8859-1 character set, .... so I suppose this makes
> the mu a Unicode character in one sense, but Unicode
> encoding is *not* required to handle a mu in any
> normal application
True. That's why I prefer that character, which the
Unicode spec actually calls "micro", to the (usually
identical-looking) one that it calls "mu", for which
Unicode encoding IS required.
> I disagree with the opinion that Symbol font is a greater
> evil and causes more problems than Unicode. For example,
> a number of applications in wide use (e.g. FrameMaker)
> do not (yet?) support Unicode at all
Hmm... In my caffeine-fueled rush to post my rant, I
might have left out a couple of sentences that would
have clarified my point.
In my opinion, an application that doesn't support
my font at all -- whether its lack of support is
demonstrated by missing symbols, symbols replaced by
little black boxes, or even outright crashes -- is
VASTLY preferable to an application that sneaks
through my document and silently multiplies all numbers
in it by 1000.
Lack of Unicode support can be seen; once seen, it can
be corrected or worked around. The mu-to-m error CAN'T
be seen; it just silently happens, and no one knows
about it until parts stop fitting together, or products
start failing, or a million pieces of the wrong
component get ordered, etc.
> if your deliverables are PDF files that have the fonts
> embedded (which should be standard practice IMO) there is
> no downside to using Symbol font.
True... UNLESS the mu-to-m error happens BEFORE the
conversion to PDF. Judging from the number of omega-to-W
errors I see in PDFs and in published books and articles,
this happens all the time.
-Andrew
=== Andrew Warren - awarren -at- synaptics -dot- com
=== Synaptics, Inc - Santa Clara, CA
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today! http://www.webworks.com/techwr-l
Easily create HTML or Microsoft Word content and convert to any popular Help file format or printed documentation. Learn more at http://www.DocToHelp.com/TechwrlList
---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-
