Path: utzoo!attcan!uunet!lll-winken!ames!oliveb!amiga!jimm
From: jimm@amiga.UUCP (Jim Mackraz)
Newsgroups: comp.sys.amiga.tech
Subject: Re: What font does Intuition use?
Keywords: Intuition, IntuiText, TextAttr
Message-ID: <3245@amiga.UUCP>
Date: 10 Jan 89 20:45:22 GMT
References: <10236@well.UUCP> <3235@amiga.UUCP> <10289@well.UUCP>
Reply-To: jimm@cloyd.UUCP (Jim Mackraz)
Organization: Commodore-Amiga Inc, Los Gatos CA
Lines: 88

In article <10289@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes:
)+-- jimm@cloyd.UUCP (Jim Mackraz) writes:
)| In article <10236@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes:
)| )When I create an IntuiText structure, I give it a pointer to a TextAttr
)| )structure to use for rendering the text.  I assume that the specified font
)| )needs to be in memory for Intuition to find it, and that if it doesn't,
)| )it will just pick a font.  Any way to find out what font it really is using?
)| 
)| It uses the current rastport font, if there is a rastport involved (e.g., 
)| PrintIText( rp, itest, l, t )).  If not, the situation is somewhat
)| ill-defined.  
)
)This is the case, I think, since this is for menus.  Just what rastport is
)involved with rendering menus seems entirely vague and deeply hidden in the
)bowels of the Intuition input device.

For menus, Intuition uses a copy of of the screen rastport made at the
time that the screen became active, whatever that means.

)| Why not do what Intuition does?  Take the rastport (or a copy of it, or
)| a new rastport with InitRastPort() ), try an OpenFont(), if succeeds, use
)| the height of the font returned, else, use the font set in the rastport.
)
)The main reason is just that I don't really know what's going on.  When
)Intuition goes to render a menu, does it do an OpenFont() each time?  If
)so, can the menu font change if the "xyz.font" mentioned in the MenuItem
)TextAttr suddenly becomes available?  If this is the case, then nothing
)I do can predict the behavior of the menu rendering.  I can make an educated
)*guess*, but I can't really *know* what Intuition is going to use as the 
)font this time. 

No, that isn't true.  You can make things completely predictable
by opening the diskfonts you need to use within your application.
That way, they'll be available.

)If the best I can do is a guess, then why bother?  The solution seems to
)be for me to pick the font directly -- i.e., try OpenDiskFont() and if
)it works, keep that font open the whole time I want to use menus.  If not,
)then modify the TextAttr to reflect the font I really got, ala.
)GetFontInfo() or whatever.  Seems like a silly thing for me to have
)to do myself though.

There you go: I guess it means you have to cache your application fonts
up front.

)I think I'll just stick to topaz8/9.  It simpler.

... or maybe "less silly."

Try to use the default system font, wherever possible.  In the future (near
future), this will be different than topaz 8/9.  It might be hard to trap
edge cases where the user changes the default system font on the fly, but
we'll minimize those and also make it <<caveat user>>: to avoid problems,
change your system font to what you want before you start applications.

It will be important to respect the default font to work nicely on higher
resolution displayes, and with the user's choice, esp. when he can choose
proportional fonts.

)| )As an aside:  Why doesn't Intuition look on disk for the font if it can't
)| )find it in memory? 
)| 
)| It has to do with general principles and specific problems.  The general
)| principle is something like "Intuition shouldn't call the DOS."
)
)Hadn't thought about that.  Yes, of course you shouldn't call DOS without
)a Process, and a library may not have one.  Also the mutual wait states, etc.
)Thanx for explaining this.

Not only does input.device not have a process (although we could make it so),
whoever calls me might not.  It's a larger thorny problem: if my library opens
another library, if that library is on disk, then my caller needs to be
a process.  This is why we have such general rules as "rom code can't rely
on disk files" and so on.  In some situations, we need to improve on this.

)		Stuart Ferguson		(shf@well.UUCP)

For V1.4, I hope that system fonts are predictable and versatile.  I'll keep in
touch with you to get your feedback down the stretch.  By the way, do you
have a copy of my DevCon paper "Application Fonts on the Amiga"?

	jimm

-- 
Jim Mackraz, I and I Computing	   	"Like you said when we crawled down
{cbmvax,well,oliveb}!amiga!jimm          from the trees: We're in transition."
							- Gang of Four
Opinions are my own.  Comments are not to be taken as Commodore official policy.