Re: Font Manager & Big Fonts

[nathan@visi.com (Nathan Mates)]

In article <6cii1d$ee4@examiner.concentric.net>,
ericlob <ericlob@cris.com> wrote:
>>   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. 

>Actually, you'd only need to patch Pointless. The App sends the font size
>to Pointless which then renders the font at various multiples of that size
>depending on the printer resolution. The maximum size with this method
>would be 255 pt but that would probably be enough for most purposes (and
>certainly an improvement over what we have now).

   Pointless (and the font mgr in general) does not know the output
resolution for scaling up. It's the Print Mgr (and/or driver) which
have the app draw into a buffer, which is made N times bigger for
rasterizing before printout. The printing system knows the scaling
factors between screen rez and printer rez, and tells the Font Mgr to
prepare N times bigger fonts. At no time does the Font Mgr know "I'm
getting this ready for a printout" which is why current 300dpi printers
have a max of 63 point fonts (255/4).

   Theoretically, you could patch both pointless and the print system
to agree that Pointless will give back a font 4x larger than asked for
if printing, but you'd quite possibly have to work on a lot of
drivers.

>>   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.

>Ok, that makes sense I guess, although I rather they'd just rewritten the
>toolset. I wonder how much time the System wastes patchings tools when it
>loads them up.

   Patching takes about zero time; set up a new TSPtr, install as
default, and it's good to go. When you have tables of pointers,
tweaking the pointers is trivial and fast.

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

>Plus RAM is faster anyways.

   *Bzzt*. ROM is actually faster, as you don't have to worry about
working around the RAM refresh signals fighting for time. You can
actually get about 2.8Mhz for ROMcode vs 2.5Mhz out of RAM, which is
why ROM 3's feel slightly faster for desktop apps.

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