shf@well.UUCP (Stuart H. Ferguson) (01/06/89)
Tell me something -- 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? Baring that, is there an equivalent to the IntuiTextLength() call for finding the font height? When I use the ta_YSize field of my TextAttr structure, but Intuition has picked another, more convient font, all my attempts at being clever in laying out text are for naught since the font is not the size I think it is. Needless to say, the results look terrible. Thanx in advance. As an aside: Why doesn't Intuition look on disk for the font if it can't find it in memory? (Or am I just off the wall on this one?) -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC
jimm@amiga.UUCP (Jim Mackraz) (01/07/89)
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. The only example I know which has IText not associated
with a rastport is IntuiTextLength( itext ). In this case, we use
a fresh rastport initialized by InitRastPort(), which sets up the graphics
default font. Intuition tries to keep graphics idea of default font in
sync with preferences and its own idea of default font.
)Baring that, is there an equivalent to the IntuiTextLength() call for
)finding the font height? When I use the ta_YSize field of my TextAttr
)structure, but Intuition has picked another, more convient font, all my
)attempts at being clever in laying out text are for naught since the
)font is not the size I think it is. Needless to say, the results look
)terrible.
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.
)Thanx in advance.
)
)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." The specific
problems are handling disk requesters gotten by OpenDiskFont(), stack
blowout in calling the dos, and probably some others that I haven't suffered
since$ haven't tried it. We're looking hard at using disk fonts (gotten from
disk) at least for the default Intuition font, so maybe we'll be able to change
this someday. In the meantime, you have to pull them in off of disk yourself.
Here's an example of the type of problem: suppose you have menu verify set,
and say PrintIText() or RefreshGList(), or anything that does text. Intuition
tries to open the font and pulls a requester. Then the user hits the menu
button. Party is over (I waits for you, and you wait for a gadget click).
Worse yet, what if Intuition pulls a requester when it is running as the input
device (refreshing your gadgets after window depth arrangement)?
)(Or am I just off the wall on this one?)
Not off the wall, you just don't appreciate how fun this job can get ... ;^)
) Stuart Ferguson (shf@well.UUCP)
) Action by HAVOC
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.shimoda@infohh.rmi.de (Markus Schmidt) (01/07/89)
Look into your Window->RPort->TextFont->tf_YSize or Screen->RPort.TextFont->tf_YSize to find the real height of the font. (btw. there is tf_XSize and tf_Flags too) Cu Markus
shf@well.UUCP (Stuart H. Ferguson) (01/10/89)
+-- 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. | 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. 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. I think I'll just stick to topaz8/9. It simpler. | )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. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC
jimm@amiga.UUCP (Jim Mackraz) (01/11/89)
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.
shf@well.UUCP (Stuart H. Ferguson) (01/17/89)
+-- jimm@cloyd.UUCP (Jim Mackraz) writes: | In article <10289@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: | )I think I'll just stick to topaz8/9. It simpler. | | Try to use the default system font, wherever possible. In the future (near | future), this will be different than topaz 8/9. | 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. Seems like a good idea, but it may not be practical without better tools. If the user picks diamond/20, for example, all my menu's are going to plunge off the bottom of the screen unless I add more code to make them wrap around. Requesters would have to be formatted on the fly, rather than built statically as they are now. It would be a really good thing, I agree, but it seems like more trouble than it's worth right now. | 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"? No. I'm sure that would make a big difference. I'll try to lay my hands on a copy. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC
jesup@cbmvax.UUCP (Randell Jesup) (01/18/89)
In article <10378@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: >+-- jimm@cloyd.UUCP (Jim Mackraz) writes: >| In article <10289@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: >| )I think I'll just stick to topaz8/9. It simpler. >| >| Try to use the default system font, wherever possible. In the future (near >| future), this will be different than topaz 8/9. >| 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. > >Seems like a good idea, but it may not be practical without better >tools. If the user picks diamond/20, for example, all my menu's are >going to plunge off the bottom of the screen unless I add more code >to make them wrap around. Requesters would have to be formatted on >the fly, rather than built statically as they are now. It would be >a really good thing, I agree, but it seems like more trouble than it's >worth right now. Menus are a tough one. You REALLY don't want them going over any edge. Also, the width/height depend on the font. Either use dynamic menu-creation code, or use a specified font for now. 1.3 Notepad has dynamic menu code, but only for the fonts menu (yes, I know, we need a font requester). Play with it and a LOAD of fonts and Setfont to get ideas about dynamic menus. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup