acs@amdahl.uts.amdahl.com (Tony Sumrall) (06/01/88)
In article <62300001@hobbiton> tran@hobbiton.prime.com writes: >I am using the Avant Garde Benchmark Modula-2 system, with SimpleModules. >My problem comes when I try to load in a disk font, "DIAMOND.20". Here are >the steps I perform: > > 1) Set up the TextAttr structure ("DIAMOND.FONT",20,{},{}). > 2) Call OpenDiskFont. > 3) Call SetFont. > >As far as I can tell, the big G comes at step 2. I believe that you need to insert a 1.5) to open the diskfont.library. > >Burton Choinski, Prime Computer Inc. Framingham, Ma. -- Tony Sumrall acs@amdahl.uts.amdahl.com <=> amdahl!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (06/02/88)
In article <62300001@hobbiton> tran@hobbiton.prime.com writes: > 1) Set up the TextAttr structure ("DIAMOND.FONT",20,{},{}). > 2) Call OpenDiskFont. > 3) Call SetFont. > >As far as I can tell, the big G comes at step 2. > One would hope that you're opening "diskfont.library" before attempting the OpenDiskFont() call... _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!pacbell -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
kodiak@amiga.UUCP (Robert R. Burns) (06/03/88)
In article <62300001@hobbiton> tran@hobbiton.prime.com writes: >My problem comes when I try to load in a disk font, "DIAMOND.20". Here are >the steps I perform: > > 1) Set up the TextAttr structure ("DIAMOND.FONT",20,{},{}). Note that font name should be "diamond.font". It turns out that, due to a side effect of implementation, "DIAMOND.FONT" will currently get you a font with the diskfont.library, but with the unwholesome caveats implied by that implementation: 1. The font will first be looked for on the graphics font list. That search uses FindName, and is thus case sensitive. 2. If the font is not found, it will be read it in from disk using the font name to find the file "FONTS:DIAMOND.FONT". Note that any case of "diaMoND.FoNT" will work, because file names are case insensitive. 3. That font will be added to the font list with the name (actually the tail of the path name) you specified in the TextAttr structure. This means your all-caps name will be used. Now someone else comes along, performs an AvailFonts to find out what fonts are available, and discovers that there is a "DIAMOND.FONT" in the memory font list, and a "diamond.font" on the disk. An attempt to load "diamond.font" will succeed, it just uses two font images where one was sufficient. Meanwhile, what name(s) should the application put in the menu? Summary (again): Font name *is* case sensitive, please use the right name - Kodiak -- | / _ _|' _ |/ Bob Burns . . . . .---. . Makers of |/ (_)(_)|(_\|\ USENET: amiga!kodiak / \ |\ /| | | __ / \ the "Power |\ Kodiak \ _______/ A \| \/ |_|_|___|/ A \ System" | \ Software "Dedicated to the Science of Fun"\_________
tran@hobbiton.prime.com (06/04/88)
[duh dah duh dah duh dah duh dah (gulp)
Thanx Chuck, Leo, et all. However, there is still a problem...how?
Like I stated, I have the Benchmark Modula-2 compiler, which comes with a huge
user's guide packed will all the definition modules and all the structure
definitions. However, there is no mention of how to initialize said
structures, nor in what order.
I have a guide "Programming on the Amiga" (or something like that) by Sybex.
It is written with C in mind. Now there are lots of things different from
C in Modula-2, so this book is of limited help.
What I need is a step-by-step, basic description of HOW to load a font.
I'm not asking people to write the program for it (although, code fragments
are welcome), just guide me through the process for the first time. This
brings me to an idea: Is there such a guide out? If not, how about a
compilation from all you Amiga Masters out there for us poor apprentices?
Include C (and Modula code) for all those new owners out there that look at
the immense complexity before them with despair. I just need a pointing hand
(or a helpful shove, kick in the right direction, hit over the head, and
other phrases) so that I can get over this brick wall in front of me.
===============================================================================
Burton Choinski, Prime Computer Inc., Framingham, Ma.
"Hacking with out Mac-ing"
CHOINSKI@ENV.PRIME.COM
-or-
TRAN@HOBBITON.PRIME.COMtran@hobbiton.prime.com (06/09/88)
[This line brought to through the miracle of modern science.....]
Aaugh! I'm gonna start pulling hair soon! The following is what I do.
All definitions are supplied below, as well as the EXACT code:
-------------------------------------------------------------------------------
VAR
Gfx, Intu, Dfon : LibraryPtr;
ft : TextFontPtr;
ta : TextAttr;
win : WindowPtr;
BEGIN
Gfx := OpenLibrary(ADR("graphics.library"),0); (* Just in case *)
Intu := OpenLibrary(ADR("intuition.library"),0); (* Just in case *)
Dfon := OpenLibrary(ADR("diskfont.library"),0);
(* Code ommited to check and see if every library opened ok. When I
run this bugger, everything opens as required *)
(* But just in case, the way I check is:
IF (Dfon = NIL) THEN .... (error) *)
ta.taName := ADR("diamond.font");
ta.taSize := 20;
ta.taStyle := FontStyleSet{};
ta.taFlags := FontFlagsSet{};
ft := OpenDiskFont(ta);
SetFont(win^.RPort^,ft^);
.
.
.
-------------------------------------------------------------------------------
Now, the code drops dead at the OpenDiskFont call. What am I doing wrong?
As far as I can see, it should work. I have added all your responses so far
(diamond.font in lowercase, adding the diskfont.library, etc) but still this
turkey refuses to fly.
Any clues, hints, pointing fingers?
===============================================================================
Burton Choinski Prime Computer Inc.
tran@hobbiton.prime.com
- or -
choinski@hobbiton.prime.com rss@ece-csc.UUCP (ML) (06/10/88)
In a previous article tran@hobbiton.prime.com wrote: >BEGIN > Gfx := OpenLibrary(ADR("graphics.library"),0); (* Just in case *) > Intu := OpenLibrary(ADR("intuition.library"),0); (* Just in case *) > Dfon := OpenLibrary(ADR("diskfont.library"),0); ... > ft := OpenDiskFont(ta); > SetFont(win^.RPort^,ft^); > >Now, the code drops dead at the OpenDiskFont call. What am I doing wrong? >As far as I can see, it should work. I have added all your responses so far >(diamond.font in lowercase, adding the diskfont.library, etc) but still this >turkey refuses to fly. I may be off base here, since I program in C and not Pascal, but ... As I understand it, routines like OpenDiskFont et al are actually stubs which use the library base pointers and apply offsets to these pointers to get a jump vector to the real routine. The library base pointer used in these routines therefore must be a global variable which also must be named correctly: GfxBase IntuitionBase DiskfontBase or whatever, rather than Gfx, Intu, and Dfon. If you OpenLibary(x) and assign it to Dfon; then call OpenDiskFont; it does something like "Jump to Subroutine @ address (DiskfontBase - 30)" -- but you haven't set DiskfontBase, just your own variable "Dfon" & so you usually get a visit from the Guru. I found (at least with Lattice C) that something somewhere apparently declares these global variables, if not actually setting them, so that the linker was NOT kind enough to tell me that "DiskfontBase" or whatever was undefined. Remember -- take this "explanation" with a grain of salt. I'm guessing, and playing footloose and fancy-free with my explanation to boot. Hope it helps... Mark Lanzo ...!mcnc!ece-csc!rss
jesup@cbmvax.UUCP (Randell Jesup) (06/10/88)
In article <62300003@hobbiton> tran@hobbiton.prime.com writes: >VAR > Gfx, Intu, Dfon : LibraryPtr; ... > Dfon := OpenLibrary(ADR("diskfont.library"),0); ... > ft := OpenDiskFont(ta); ... >Now, the code drops dead at the OpenDiskFont call. What am I doing wrong? >As far as I can see, it should work. I have added all your responses so far >(diamond.font in lowercase, adding the diskfont.library, etc) but still this >turkey refuses to fly. I don't know how your system handles libraries, but for all languages I've seen, the library pointer must go in a global variable of a specified name so the interface routine (for OpenDiskFont) can find it. How else is the interface code for OpenDiskFont supposed to know that there is a valid DiskFont library pointer around? You don't pass it to the code, so it must be looking for a global somewhere. Read your compiler documentation for interfacing with library routines. Note: the same problem applies to the other libraries, unless the system happens to have opened them already (like C startups open dos.library for you). Randell Jesup, Commodore Engineering {uunet|rutgers|ihnp4|allegra}!cbmvax!jesup
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (06/10/88)
In article <62300003@hobbiton> tran@hobbiton.prime.com writes: >Aaugh! I'm gonna start pulling hair soon! The following is what I do. >All definitions are supplied below, as well as the EXACT code: >------------------------------------------------------------------------------- > >VAR > Gfx, Intu, Dfon : LibraryPtr; > >BEGIN > Gfx := OpenLibrary(ADR("graphics.library"),0); (* Just in case *) > Intu := OpenLibrary(ADR("intuition.library"),0); (* Just in case *) > Dfon := OpenLibrary(ADR("diskfont.library"),0); > I have *no* idea how Modula-2/Pascal deal with symbol names, or how their Amiga library stubs work, but it occurs to me that you should be saying: VAR GfxBase, IntuitionBase, DiskFontBase : LibraryPtr; BEGIN GfxBase := OpenLibrary (ADR("graphics.library"), 0); (* et cetera, et cetera, et cetera... *) The library stubs in C require that you store the library base pointer into a pointer variable with a specific name (in this case, GfxBase, IntuitionBase, et al). This is so that the linker can resolve the reference between your code and the library stubs. You may wish to check that your DiskFontBase pointer is named correctly. However, I have *NO* idea how Modula does it, so I may be completely off base here.... _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!pacbell -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Hmm, you're right. Air is made up of suspended meat loaf." -- Josh Siegel
choinski@hobbiton.prime.com (06/11/88)
[Halt, Evil Line Eater, and return to whence thou came!] And there was much rejoicing.... Thanx Leo, Bob, Mark et all! It works now! Now I DON'T have to use TOPAZ.8 for the rest of my life! Really, you helped me a great deal. I was ready to give up on trying other fonts and just use TOPAZ.8 with a low-rez screen, but no more! Again, thanx! =============================================================================== Burton Choinski Prime Computer Inc. At: choinski@hobbiton.prime.com Framingham, Ma. 01701
haitex@pnet01.cts.com (Wade Bickel) (06/12/88)
If you are using Benchmark just import "GfxBase" from the "System"
module found in the M2L directory (NOT TO BE CONFUSED WITH "SYSTEM").
The graphics library will be opened for you and you can then say
Gfx := GfxBase;
At least, that's how I do it.
Good Luck,
Wade.
UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
ARPA: crash!pnet01!haitex@nosc.mil
INET: haitex@pnet01.CTS.COMbrianr@tekig4.TEK.COM (Brian Rhodefer) (06/14/88)
Am I all wet in thinking that the fact one can write code that puts the library base vectors into globals with names that don't agree with the libraries' declared globals, and then compile and link this code with those libraries WITHOUT THE SLIGHTEST COMPLAINT from the linker demonstrates a serious weakness in the language? Dejectedly, Brian Rhodefer ...!tektronix!tekig4!brianr
blandy@awamore.cs.cornell.edu (Jim Blandy) (06/14/88)
In article <2930@tekig4.TEK.COM> brianr@tekig4.UUCP (Brian Rhodefer) writes: > [ a plaintive complaint about library bases and stuff ] Now Modula-2 is not my language, but doesn't the language specify that modules can provide some initialization code, guaranteed to be run if the module is used? If you have a module for each library, shouldn't this initialization code open the library? C uses a very simple model for where functions come from, so some neato self-opening libraries would be a pain - if you were using C, I'd say "tough. get disciplined :-)," but it seems like something Modula-2 should do. Anyone know for sure? -- Jim Blandy - blandy@crnlcs.bitnet "insects were insects when man was just a burbling whatsit." - archie How necessary ARE disclaimers, anyway?
jimm@amiga.UUCP (Jim Mackraz) (06/15/88)
In article <2930@tekig4.TEK.COM> brianr@tekig4.UUCP (Brian Rhodefer) writes:
)Am I all wet in thinking that the fact one can write code that
)puts the library base vectors into globals with names that don't
)agree with the libraries' declared globals, and then compile
)and link this code with those libraries WITHOUT THE SLIGHTEST COMPLAINT
)from the linker demonstrates a serious weakness in the language?
)Dejectedly,
)Brian Rhodefer ...!tektronix!tekig4!brianr
Yet another person complaining about the C language when the problem is
in the implementation, and in this case, not even the implementation
of the C part, but the Amiga interface.
Linker I use will complain if you call an Intition function and don't
have IntuitionBase defined in YOUR code (you don't declare it extern,
you define it). Works great. Nobody keeps you from stuffing
a pointer to your middle name in IntuitionBase, though.
I claim the serious weakness is not in the language in this case.
jimm
--
Jim Mackraz, I and I Computing
amiga!jimm BIX:jmackraz
Opinions are my own. Comments regarding the Amiga operating system, and
all others, are not to be taken as Commodore official policy.peter@sugar.UUCP (Peter da Silva) (06/15/88)
In article <2930@tekig4.TEK.COM>, brianr@tekig4.TEK.COM (Brian Rhodefer) writes: > Am I all wet in thinking that the fact one can write code that > puts the library base vectors into globals with names that don't > agree with the libraries' declared globals, and then compile > and link this code with those libraries WITHOUT THE SLIGHTEST COMPLAINT > from the linker demonstrates a serious weakness in the language? No, you're not all wet. You're damp, though. The conclusion you should have come to is that there's a deficiency in the implementation. I get complaints from the linker when I don't have the right names defined, with Manx. Which compiler are you using, and which libraries are you talking about? Some are opened in _main(), you know. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These may be the official opinions of Hackercorp.