chas@gtss.UUCP (Charles Cleveland) (01/19/88)
This is about fonts and structures which indicate them. Here is a newly opened Window. Its structure has a pointer to a Rastport structure which contains a pointer to a TextFont structure. The Window also contains a pointer to its parent Screen's structure. This structure contains a pointer to a TextAttr structure along with a pointer to the Screen's Rastport structure which of course also contains a pointer to a TextFont structure. Perhaps there are other related TextAttr/TextFont structures I have overlooked. If so, I would like to know of them. I am interested in knowing how the values of these structures are related to one another. What determines Window's Rastport's TextFont when it is opened? Are the Screen's TextAttr and its Rastport's TextFont related, perhaps only during the latter's initialization? In what (possibly independent) ways are the Screen's TextAttr & its RastPort's TextFont used? For example, my Addison-Wesley Intuition Reference Manual says that a string gadget "inherits ... the font of the screen in which it appears." Well, which font is that? Can I in any way change the font for my String Gadgets without changing a default font for my entire Screen? Apart from a desire to understand the relations between these structures for future use, I simply want to set the font used by Text() in the window (ala SetFont) to that which will be use by Intuition string gadgets, regardless of the mindless antics someone may have played with SetFont or its equivalents. I would also like to know which font structure has been thereby set (or which structure it was set from) so that I can determine its size for scaling purposes. ------------- I have had embarrassingly inordinate difficulty opening a TextFont from the Screen's TextAttr structure. Apparently, (from memory) tf = (struct TextFont *)OpenFont(WindowPointer->WScreen->Font); results in a Guru with an illegal instruction error. I will shortly explore this further. Undoubtedly I am doing something stupid that invokes the Guru, but it keeps me from testing out some of the alternatives which might enable me to sort this out by myself [Lattice 3.03 -- I promise I'll upgrade soon :-)]. In the meantime I would appreciate any info about how these structures relate to one another and their uses. Perhaps that will inspire comprehension as to why my OpenFont call fails. Best regards to all. -- -Life would be so much easier if we could just look at the source code.- Charles Cleveland Georgia Tech School of Physics Atlanta, GA 30332 UUCP: ...!gatech!gtss!chas INTERNET: chas@ss.physics.gatech.edu
cmcmanis%pepper@Sun.COM (Chuck McManis) (01/20/88)
Ah yes, fonts, and a funny bunch of things they are too... In article <196@gtss.UUCP> (Charles Cleveland) writes: |> Here is a newly opened Window. Its structure has a pointer to a Rastport |> structure which contains a pointer to a TextFont structure. Yes, and the thing to note is that every RastPort has it's own Font. Windows can have up to three RastPorts associated with them. (Window, Titles, Menus) |> The Window also contains a pointer to its parent Screen's structure. This |> structure contains a pointer to a TextAttr structure along with a pointer |> to the Screen's Rastport structure which of course also contains a pointer |> to a TextFont structure. The thing to note here is that the programmer can open a Screen with a NULL TextAttr structure pointer, meaning "Open the default font." I believe that the TextFont structure is simply copied from the workbench screen in this case and no effort is made to reverse engineer that into a TextAttr structure for the Screen. |> Perhaps there are other related TextAttr/TextFont structures I have |> overlooked. If so, I would like to know of them. As above, Every rastport has a font associated with it, and screens, windows, window titles, menus, and requesters all have a RastPort associated with them. |> I am interested in knowing how the values of these structures are related |> to one another. What determines Window's Rastport's TextFont when it is |> opened? Jimm could answer for sure but the answer seems to be that the TextFont structure of a window's RastPort is copied from the screens RastPort. This is because the actual bits in your window's bitmap (if you haven't allocated them separately to make a superbitmap window) are the same ones in the Screens bitmap. So my guess is that the Rastport struct is copied directly from the screens and then fixed up to reflect different sizes that the window actually uses. After a window is open you can use SetFont() on it's RastPort to change it's Font. |> Are the Screen's TextAttr and its Rastport's TextFont related, |> perhaps only during the latter's initialization? In what (possibly |> independent) ways are the Screen's TextAttr & its RastPort's TextFont used? I have found thru experimentation that the Screen's TextAttr and TextFont are related but you can't count on them per se. If the NewScreen structure had a NULL TextAttr then the Screen will have one as well, however if you put {"siesta.font",11,FSF_ITALIC,FPF_TALLDOT+FPF_DISKFONT} into the TextAttr pointer, but either diskfont.library wasn't open or Siesta 11 wasn't found then you will get 'the next best thing' to put into your TextFont structure. (usually TOPAZ60). |> For example, my Addison-Wesley Intuition Reference Manual says that a string |> gadget "inherits ... the font of the screen in which it appears." Well, |> which font is that? Can I in any way change the font for my String |> Gadgets without changing a default font for my entire Screen? String gadgets are broken. They inherit the font from the screen but are rendered in Topaz until they are selected. It looks pretty bogus when your string gadget changes fonts but that is all you can do. (unless you build your own string gadget). |> Apart from a desire to understand the relations between these structures |> for future use, I simply want to set the font used by Text() in the window |> (ala SetFont) to that which will be use by Intuition string gadgets, |> regardless of the mindless antics someone may have played with SetFont or |> its equivalents. I would also like to know which font structure has been |> thereby set (or which structure it was set from) so that I can determine its |> size for scaling purposes. Thats simple, always Setfont your window to Topaz60 or 80 and this should work just fine. |> I have had embarrassingly inordinate difficulty opening a TextFont from the |> Screen's TextAttr structure. Apparently, (from memory) |> tf = (struct TextFont *)OpenFont(WindowPointer->WScreen->Font); This will fail if a) Font is NULL, or b) Font is a Disk font. You should check for NULL first, and then check for FPF_DISKFONT. |> results in a Guru with an illegal instruction error. I will shortly explore |> this further. Undoubtedly I am doing something stupid that invokes the Guru, |> but it keeps me from testing out some of the alternatives which might enable |> me to sort this out by myself [Lattice 3.03 -- I promise I'll upgrade |> soon :-)]. In the meantime I would appreciate any info about how these |> structures relate to one another and their uses. Perhaps that will inspire |> comprehension as to why my OpenFont call fails. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
chas@gtss.UUCP (Charles Cleveland) (01/21/88)
Re font structures per se, conflicting reports are still coming in. But
perhaps one of you can help me with a related problem alluded to in my
original posting.
Here is a reduced version, OFT.c, of the program in which I have a problem
with an OpenFont call. This program was compiled with Lattice 3.03 with no
options except that stack checking was disabled so that I could link just
to AStartup.obj, although it is likely to compile under anything.
It was compiled via
lc1 OFT
lc2 -v OFT
and linked using Blink 6.5 like this:
blink lib amiga.lib from Astartup.obj,OFT.o
It is imagined that the program will be executed from a system running
without the benefit of SetFont or its brethren, that is, one using only one
of the ROM topaz fonts, so that OpenFont will suffice and diskfont.library
does not need to be opened. However, the program still SHOULD not
misbehave even if this condition does not hold.
If I compile the program as listed and run it, I just get a window that
opens and closes quick as a bunny. If I redefine CRASH to be TRUE and
recompile, running the program generates a GURU indicating an illegal
instruction trap although I think I should still just get a window that
opens and closes quick as a bunny.
I do not understand. I hesitate to infer that the WorkBench Screen the system
provides by default has not a NULL TextAttr but a garbaged one. Would someone
please point out the manifestation of my brain damage in the next 34 lines?
#define INTUITION_REV 33
#include <exec/types.h>
#include <exec/exec.h>
#include <intuition/intuition.h>
#include <graphics/gfxbase.h>
#define CRASH FALSE
struct TextFont *font;
struct TextAttr *TAttr;
struct IntuitionBase *IntuitionBase;
struct GfxBase *GfxBase;
struct Window *wp;
struct NewWindow NewWindow={
0,0,320,100,3,1,NULL,NULL,NULL,NULL,"OpenFontTest",NULL,NULL,0,0,0,0,
WBENCHSCREEN
};
main()
{
IntuitionBase=(struct IntuitionBase *)
OpenLibrary("intuition.library",INTUITION_REV);
if(IntuitionBase==NULL)Exit(300);
if((wp=(struct Window *)OpenWindow(&NewWindow))==NULL)Exit(301);
TAttr=wp->WScreen->Font;
if(TAttr){
if(CRASH)font=(struct TextFont *)OpenFont(TAttr);
}
CloseWindow(wp);
CloseLibrary(IntuitionBase);
}
--
-Life would be so much easier if we could just look at the source code.-
Charles Cleveland Georgia Tech School of Physics Atlanta, GA 30332
UUCP: ...!gatech!gtss!chas INTERNET: chas@ss.physics.gatech.educhas@gtss.UUCP (Charles Cleveland) (01/23/88)
I would like to thank everyone for not pointing out what was wrong with the program I posted. Now that I figured it out I guess I'll get a flurry of answers. Serves me right. The new question is "What does the graphics.library function SetFont set besides the Window's RastPort's TextFont?" Thank you for your support. -- -Life would be so much easier if we could just look at the source code.- Charles Cleveland Georgia Tech School of Physics Atlanta, GA 30332 UUCP: ...!gatech!gtss!chas INTERNET: chas@ss.physics.gatech.edu