Steve_A_Hales@cup.portal.com (12/18/87)
Augh!!!!
Ok, like, don't laugh! Ok, Ok.... Whad' I say.... Whad' I say...
Aloha!
I have this real strange font related problem (no, not again).
I've opened a font with OpenDiskFont. It returns a pointer to
the TextFont structure. Well, I need to obtain the name of the
font from the TextFont structure, and guess what, it changes!
The following dump is of the TextFont structure. Note that
the ln_Name pointer is valid and is pointing to the correct
name.
...
OpenFont 0 .. Failed
OpenDiskFont ( ->ln_Name )
21988a: 00 20 06 36 00 20 06 f8 0c 00 00 21 98 6a 00 00 . .6. .x...!.j..
21989a: 00 00 2c 9c 00 26 40 62 00 1c 00 18 00 01 00 01 ..,..&@b........
2198aa: 20 7f 00 21 98 fa 00 c4 00 21 d3 2a 00 21 d4 ae .!.z.D.!S*.!T.
2198ba: 00 21 d5 70 00 01 02 01 00 03 ff 00 00 21 98 ea .!Up........!.j
Sizes 38 38
21986a: 42 61 6c 6c 6f 6f 6e 2e 66 6f 6e 74 00 20 20 20 Balloon.font.
21987a: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
...
The following dump is from the same program while still running,
and the font from above is still in memory, but this time, I'm
accessing a different font and the ln_Name pointer points to
some random memory block.
...
OpenFont 0 .. Failed
OpenDiskFont ( ->ln_Name )
21dc5a: 00 20 06 36 00 21 98 8a 0c 00 00 45 27 1e 00 00 . .6.!.....E'...
21dc6a: 00 00 00 00 00 32 00 62 00 3d 00 21 00 01 00 01 .....2.b.=.!....
21dc7a: 20 7a 00 21 dc 8e 01 20 00 22 14 ce 00 22 16 3e z.!\.. .".N.".>
21dc8a: 00 22 16 f6 00 00 00 61 80 00 f1 e0 00 00 00 00 .".v...a..q`....
Sizes 50 50
45271e: 3f 00 3f 00 3f 00 3f 00 3f 00 3f 00 3f 00 3f 00 ????????
45272e: 3f 00 3f 00 3f 00 3f 00 3f 00 3f 00 3f 00 3f 00 ????????
I have also disovered that when you attempt to close this font, it
will close, but when you then make a call to AvailFonts, the system
will thrash it self around, and return with random results.
My question is clear -- WHAT'S GOING ON!!?!?
Does anyone have any clue what so ever? This is very repeatable, using
specific fonts. However I am using the ColorFont structure from
Inter/Active, but that really should make no difference.
What I think is happening is when AmigaDOS loads the font into memory,
it is not loading the tf_Message.mn_Node.ln_Name pointer from the
TextFont structure correctly.
Well, thanks in advance. I really don't know if anyone can help, but
if you have any new angles, please drop me a clue.
- Steve Hales
UUCP: Steve_A_Hales@cup.portal.comkodiak@amiga.UUCP (Robert R. Burns) (12/22/87)
In article <2041@cup.portal.com> Steve_A_Hales@cup.portal.com writes: > Augh!!!! ... > I have this real strange font related problem (no, not again). > I've opened a font with OpenDiskFont. It returns a pointer to > the TextFont structure. Well, I need to obtain the name of the > font from the TextFont structure, and guess what, it changes! ... >OpenDiskFont ( ->ln_Name ) >21dc5a: 00 20 06 36 00 21 98 8a 0c 00 00 45 27 1e 00 00 . .6.!.....E'... > Does anyone have any clue what so ever? This is very repeatable, using > specific fonts. However I am using the ColorFont structure from > Inter/Active, but that really should make no difference. ^^^^^^^^^^^^^^^^^^^^^^^^^ BRRRAAAP! Here's the bug: when you use InterActive's Calligrapher to create a font from scratch, it does not correctly create a load image whose ln_Name is just the relocation value. If the font is just a modification of a good old one, everything's fine. I see from the ln_Name you have that expansion memory was used when this font was first created, thus the absolute ln_Name value was 0x2xxxxx. When "relocated" to 21dcxx, you get the trashed 0x45271e. Unfortunately, the diskfont.library loads a font, adds it to the list of fonts, and returns you a pointer to the font without getting that pointer from the font list. (If it had been gotten from the list, 1. it would be larger and slower, but 2. this bug would have been caught sooner.) Now that the font is on the font list, AvailFonts will tell you about it, bad name and all: remember that the name is null terminated and that the name is stored in the buffer you give AvailFonts. InterActive has written a font patcher to fix up all your fonts -- This longword in the file should always have the value 0x0000001a, which, if you look at "libraries/diskfont.h", is the loaded offset of dfh_Name. If you have a binary file editor, I think you'll find this longword at offset 0x64 into the font file. SO... set the longword at 0x64 in the font file to 0x0000001a and you're fixed. >UUCP: Steve_A_Hales@cup.portal.com - Bob "Kodiak" Burns