Re: Font Manager & Big Fonts

[nathan@visi.com (Nathan Mates)]

In article <6cgvjv$84f@examiner.concentric.net>,
ericlob <ericlob@cris.com> wrote:
>> Basically, when Apple designed the GS, they decided to try and
>>skimp on bytes, limiting fonts to 255 points. There are only 8 bits
>>(==256 possibilities) for font size, and extending that would require
>>rewriting both the Font Manager *and* every app using it. 

>After looking at it, my thoughts were that the best solution would
>be to add new functions to the font manager toolset (InstallFont2,
>etc) and patch Pointless. People without TrueType fonts probably
>wouldn't print larger anyway.

   You're still running up against the problem noted above that you'd
need to patch the FontManager, *and* any app that wanted to use
extended functions. If the Font Mangler internally uses 8-bit values
for font size, then apps almost certainly do so also, and you'd have
to do major surgery to get any existing app (AWGS and GraphicWriter
III are about the main two GS programs used for DTP) before they'd
support that. And that'd involve everything from loading & saving the
slightly larger files, etc. Not a pretty sight, really.

>No, I meant why didn't Apple just add the new code to the toolset rather
>than having TS2 patch them out.

   TS2/3 tend to have patches if the toolset is in ROM on one or both
machines. If the actual toolset is purely rambased, then they can be
updated by simply tweaking the ToolXYZ file on disk, but if it's in
ROM on one, and RAM on the other, you'd have version-specific code in
the toolXYZ file, while it's supposed to be the job of TS2/TS3 to
handle that.

   I think that Apple learned the hard way that freezing versions in
ROM can lead to a lot of headaches in patches later (they explicitly
admit to doing that in their warnings on 'tailpatching' toolsets, as
some functions determine if they're being called from ROM and do
special things in such cases). It woulda been better to have a smaller
ROM with more RAM to compensate, and then there would not have been
all these patching and version headaches.

   If something is going to change a lot, dump it in RAM, or you'll
have lots of problems later.

>And yes, this would slow things down considerably, just like 600dpi
>printing would, but it would do alot towards making the GS a semi-viable
>home publishing platform.

   You're still running into the consideration that one of the best
and most stable GS word processors is Appleworks classic v5.1. Most GS
word processors can be buggy, flakey, and feature-poor compared to a
decked out AW5.1 with a good macro set and addons. Sure, AW classic is
less point-and-drool WYSIWYG (like the GS's oddball aspect ratio can
ever do WYSIWYG text and graphics at the same time), but it's more
productive, stable, and feature rich.

    With almost-necessary addons like Pointless showing up later in
the GS's life (as seen by commercial companies making word
processors), GS's being underpowered in the RAM dept (necessary for
DTP), and Apple's 'Word processor in a box' of TextEdit both sorta
muscling out most competition and being highly flakey, the GS DTP
scene could definitely be a lot better.

Nathan Mates
--
<*> Nathan Mates http://www.visi.com/~nathan/      <*>
# What are the facts? Again and again and again-- what are the _facts_?
# Shun wishful thinking, avoid opinion, care not what the neighbors
# think-- what are the facts, and to how many decimal places? -R.A. Heinlein