home *** CD-ROM | disk | FTP | other *** search
/ World of Shareware - Software Farm 2 / wosw_2.zip / wosw_2 / QBAS / PRINTROM.ZIP / ARTICLE.DOC next >
Text File  |  1991-09-03  |  13KB  |  243 lines
  1.      ----------------------------------------------------------------------
  2.                    P R I N T R O M  -  F O N T   M A C H I N E
  3.      ----------------------------------------------------------------------
  4.  
  5.      Fonts in a Can by Larry Stone
  6.  
  7.         You know how it goes - in the process of creating a nifty  program,
  8.      you get side tracked on an even more  nifty  subprogram.   Eventually,
  9.      this nifty subprogram turns into an extrodinary piece of  work.   Such
  10.      is the story behind PrintROMtable - a routine to produce a library  of
  11.      graphics fonts without a font library!
  12.  
  13.         The original PrintROMtable was developed for  FUSION  (published in
  14.      The QBNews vol 2, issue ?).  Based upon code published by PC Magazine,
  15.      PrintROMtable was limited in it's scope.   Because my time,  like most
  16.      of us, is limited, I made an early release of the code on the Quik_BAS
  17.      internation echo, and asked others to join in it's  development.   The
  18.      responce was outstanding.  Rob Smetana immediately jumped into it with
  19.      code to create italics.  Francois Roy supplied code to elongate  char-
  20.      acters for a bold appearance.   Bill Beasley supplied code  to  create
  21.      tall characters, inspiring Mike Kelly to offer code that creates fonts
  22.      that are 8, 14, 16, 28, or 32 pixel points in height.   Both  Rob  and
  23.      Mike supplied code to allow CGA systems access to the  extended  ASCII
  24.      set (characters 128 through 255). Of course, my contribution continued
  25.      with left-handed italics,  underlined characters, inverse and backward
  26.      characters, strike through, stencil characters, double wide  and  even
  27.      condensed characters, and, not least of all, intergrating the  various
  28.      code supplied by the other, aforementioned contributors, into the  one
  29.      highly useful and variable module. You know how it goes - while in the
  30.      process of creating a nifty program, it goes on and on and on...
  31.  
  32.         Before we get much further,  you should know that PrintROM  is  run
  33.      from a test program called, ROMtest.bas,  and,  although ROMtest traps
  34.      and sets the screen to your highest resolution, the pixel  positioning
  35.      is coded for SCREEN 12. This means that if your computer monitor can't
  36.      handle this resolution then you will see only some of the nifty things
  37.      displayed or, in some cases, some of the diplay will be outside of the
  38.      monitor's graphic boundaries (you can always tweek the xAxis and yAxis
  39.      locations coded in the ROMtest program to place any string  into  your
  40.      system's view area).
  41.  
  42.         So, what's so special about PrintROMtable?   Plenty!   It is a huge
  43.      library of fonts without needing external libraries! The external libs
  44.      supplied provide extended ASCII set 128 through  255.   These are  not
  45.      necessary to the program unless your system is CGA and passes a string
  46.      containing a high ASCII character to PrintROMtable.  Even if your pro-
  47.      gram runs on EGA or VGA, you may wish to include one or more of  these
  48.      font files for the special characters they provide, such as the  copy-
  49.      right and registered trade mark symbols  (more on this subject later!)
  50.      PrintROMtable compiles to around a 13K object file - as small or smal-
  51.      ler than most "standard" font libraries!  As small as this is, you are
  52.      provided fonts ranging from 8 to 64 pixels tall in condensed,  normal,
  53.      bold, or double wide sizes; characters can  be  underlined,  shadowed,
  54.      italic (slanted left or right),  inverted,  backwards,  stenciled,  or
  55.      contain a strike through mark.   Furthermore, you can print from  left
  56.      to right, right to left, top-down, bottom-up, or even at an angle!
  57.  
  58.         PrintROMtable has limitations.  CGA systems can only use characters
  59.      8 pixels tall - this can be expanded to 16 by setting  PR.Tall = True.
  60.      EGA systems cannot access sizes 16, 32.   However, EGA can have size 8
  61.      expanded to 16 by setting PR.Tall = True.   If you try to have an  EGA
  62.      system use font size 16 or 32, PrintROMtable will reset the size to 14
  63.      or 28, respectively.  This means that using PR.Height = 32 and PR.Tall
  64.      equals True on EGA systems will produce a font 56 pixels high,  not 64
  65.      as intended.   Only VGA has the entire range of  8, 14, 16, 28, 32, 56
  66.      and 64 height characters.
  67.  
  68.         The heart of PrintROMtable is it's code to access the  where-abouts
  69.      of the ROM BIOS segment containing the character shape table.
  70.  
  71.         Once PrintROMtable has the pointer into the ROM segment  that  con-
  72.      taining the character shape tables,  it loops  through  the  passed-in
  73.      string, once for each character in the string.   If a background color
  74.      is called for, it uses LINE with a box and fill (BF) argument to paint
  75.      a background color.   If a background color is not requested then  the
  76.      background color is transparent.  The code then loops 4, 8, 14, 16, 28
  77.      32, 56, or 64 times for each scan line of the character  (depending on
  78.      such factors as PR.Height, PR.Condesned, and PR.Tall).
  79.  
  80.         The 1st item of business is to determine what value, based upon the
  81.      font size, need to be loaded into the BX register so that a subsequent
  82.      call to BIOS interrupt 10h, function 1130h can point us to the correct
  83.      memory address containing our scan lines:
  84.  
  85.              SELECT CASE PR.Height
  86.                  CASE 8               ' 8x8 font
  87.                      reg.bx = &H300
  88.                  CASE 14, 28          ' 8x14 font or 8x14 font double high
  89.                      reg.bx = &H200
  90.                  CASE 16, 32          ' 8x16 font or 8x16 font double high
  91.                      reg.bx = &H600
  92.                  CASE ELSE
  93.                      CLS : PRINT "Invalid Character Size": END
  94.              END SELECT
  95.  
  96.         Having determined the BX value, PrintROMtable then sets AX = &H1130
  97.      before it calls BIOS Video Service, &H10:
  98.  
  99.                 reg.ax = &H1130
  100.                 InterruptX &H10, reg, reg
  101.                 ofst& = reg.bp
  102.                 sgmt& = reg.es
  103.  
  104.      For those with inquiring minds, function AX = 1130h is called with  AX
  105.      and BX set as follows:
  106.  
  107.                 AX = 1130h
  108.                 BX = pointer specifier
  109.                     &H0   INT 1Fh pointer
  110.                     &H100 INT 44h pointer
  111.                     &H200 ROM 8 by 14 character font pointer
  112.                     &H300 ROM 8 by 8 double dot font pointer
  113.                     &H400 ROM 8 by 8 DD font (top half)
  114.                     &H500 ROM alpha alternate (9 by 14) pointer
  115.                     &H600 ROM alpha alternate (9 by 16) pointer
  116.  
  117.      On return, the ROM BIOS function supplies:
  118.  
  119.                 ES:BP = specified pointer
  120.                 CX    = bytes/character
  121.                 DL    = character rows on screen
  122.  
  123.         Even though PrintROMtable has the appropriate segment and offset to
  124.      the character shape table, they may not be correct!  The above call to
  125.      the BIOS is only good for EGA, MCGA, or VGA systems.  If PR.ScreenMode
  126.      is less than 7 or, if you tell PrintROMtable to force the CGA  address
  127.      then PrintROMtable sets the character shape table's segment to &HFFA6.
  128.  
  129.            IF PR.ForceAddress OR PR.ScreenMode < 7 THEN sgmt& = &HFFA6
  130.  
  131.      Segment &HFFA6 contains the character table but,  unlike  our  INT 10h
  132.      table pointer, this table only goes to the first 127 ASCII characters.
  133.      This means that if PR.ScreenMode is  1, 2, or 3  (same as SCREEN 1, 2,
  134.      or 3) or, if you instruct PrintROMtable to force the address then, you
  135.      cannot access the upper ASCII set without defining a disk font file.
  136.  
  137.         Since the objective of all of the contributors to this program  was
  138.      to create a self-contained, linkable module, we wanted to avoid asking
  139.      users to have to have, or load,  a 3rd-party file just to  access  the
  140.      upper ASCII character set. Several people answered our call for ideas.
  141.  
  142.         Mike Kelly was 1st to supply code to accomplish this aim.  Although
  143.      his code was self-contained, it required 4k of memory to use the data.
  144.      Cornel Huth described an approach similar to the one eventually  taken
  145.      with PrintROMtable: to use Int 1Fh to point to an array containing the
  146.      high characters. Similar approaches were suggested by Bill Beeler  and
  147.      Dave Cleary.  The final approach developed was by Rob Smetana  and  is
  148.      similar in operation to the  DOS program,  Graftabl.  Unlike Graftabl,
  149.      Rob's approach does not require a TSR and it uses a meager 1024  bytes
  150.      of memory.  It does, however, use small, 1024 byte external files.
  151.  
  152.         External fonts are loaded by the routine with one GET statement:
  153.  
  154.            j% = FREEFILE                         'Get a handle
  155.            OPEN FontFile$ FOR BINARY AS #j%      'Open with this handle
  156.            font$ = SPACE$(1024) 'Our fonts need just 1024 bytes (128 * 8).
  157.            GET #1, , font$: CLOSE #j%            'Close file with handle j%
  158.  
  159.         PrintROMtable is supplied with four disk font files that access the
  160.      characters used in international, U.S., Portuguese,  and French-Canada
  161.      ASCII sets.  There can be additional 1024 font files added to the list
  162.      by altering the appropriate area of the PrintROMtable routine.  To add
  163.      a new font file, search PrintROMtable for:
  164.  
  165.                 '**** You could create your own 1024 byte
  166.  
  167.      The code is self-expanatory and you should not have any trouble adding
  168.      to the list.
  169.  
  170.         If your program is to access one or more of these font  files,  you
  171.      might want to establish a default file to use  (if you don't designate
  172.      a default file then the routine sets the default to number 1 -- inter-
  173.      national).   To set a default font file, before you make any calls  to
  174.      PrintROMtable, LET PR.DefaultFile = ?    Where ? is the number of  the
  175.      file to use (presently, 1 through 4).
  176.  
  177.         Whether a default font file is established or not, you can,  at any
  178.      time, instruct the routine to load any of the font files.   First, you
  179.      should reset the current font file:
  180.  
  181.                             PR.ReadHiAscFile = -1
  182.                             CALL PrintROMtable(a$, PR)
  183.  
  184.      Then, to set the new file, simply:
  185.  
  186.                         PR.ReadHiAscFile = 2 (or 3, or 4, etc.)
  187.  
  188.      The next call to PrintROMtable will then read and use the new fonts.
  189.  
  190.         If your font files are not located in the default path,  before you
  191.      you make your first call to PRINTROMtable, you need to inform it where
  192.      to look.  This, too, is a simple instruction:
  193.  
  194.                         LSET PR.DiskFontLoc = "C:\OFF\IN\URANUS"
  195.  
  196.         Many QB programmers set their SCREEN mode by using  literals,  ie.,
  197.      they use code similar to, SCREEN 9.   PrintROMtable needs to know what
  198.      screen you are using.   To inform it which screen mode is in  use,  do
  199.      something like:
  200.  
  201.                         PR.ScreenMode = 12
  202.                         SCREEN PR.ScreenMode
  203.  
  204.         Putting it all together, your program should look something like:
  205.  
  206.             REM $INCLUDE: 'printrom.bi'
  207.  
  208.             LSET PR.DiskFontLoc = "D:\SNAZZY\FONT\AREA\"
  209.             PR.DefaultFile = 1
  210.  
  211.             PR.ScreenMode = 9
  212.             SCREEN PR.ScreenMode
  213.  
  214.             PR.Height = 8: PR.xAxis = 20: PR.yAxis = 30
  215.             PR.StepX = 9: PR.CharClr = 15: PR.Shadow = -1
  216.             PrintROMtable "Hello there, my name is", PR
  217.  
  218.             PR.Tall = -1: PR.xAxis = 20: PR.yAxis = 48
  219.             PrintROMtable "John Doe", PR
  220.  
  221.         When working from within the QB environment,  you need to  load  QB
  222.      by typing, "QB /Lqb".  The sample program that demonstrates how to use
  223.      PrintROMtable is named, "ROMTEST.BAS". It is in the file, PRINTROM.ZIP
  224.      along with PRINTROM.BI, and ROMTEST.MAK. Run QB with the "/Lqb" switch
  225.      then open the file RomTest.Bas.  That's all you have to do.
  226.  
  227.         One final note.  PrintROMtable can do a great deal of fancy work to
  228.      your strings.  The fancier your output, the more time required to per-
  229.      form the work.  One saving grace is that all of the fancy manipulation
  230.      performed by PrintROMtable is considerably faster once compiled as  an
  231.      EXE file.  However, compiled or not, expect certain processes, such as
  232.      PR.Elongate = 2 (double wide) to be slower than the simpler  processes
  233.      like 8 pixel high, normal character writes.
  234.  
  235.      **********************************************************************
  236.           Larry  Stone is President of LSRGroup and is involved in  writing
  237.      instructional and large data base application systems for business and
  238.      institutional clients.  He is also the author of SERVICES, a shareware
  239.      application program rated a trophy by "Public Brand Software". He  can
  240.      be  reached  at LSRGroup, 2945 "A" Street, North Bend, OR 97459, or in
  241.      care of this newsletter.
  242.      **********************************************************************
  243.