mdf@tut.cis.ohio-state.edu (Mark D. Freeman) (12/15/87)
I just upgraded from 3.1 to 4.0. I use an Okidata Laser, and under 3.1 I used the HPLASPS driver, as there wasn't an OKILASER driver yet. In switching over to the OKILASER driver, I noticed something rather odd. The TMSRMN font was roman-a in one driver and roman-i (or some other variant) in the other. This meant either modifying the OKILASER driver to match the HPLASPS driver, or changing all my style sheets. Is this a screw-up by Microsoft, or is there some good reason for this? I have yet to move from one printer to another without having to change the fonts in my style sheets, as they don't seem to use any sense in assigning fonts (e.g. NLQ) to font-codes (e.g. modern-a). This renders style sheets much less useful than they could be, particularly in organisations with more than one type of printer. (We also use a NEC P5-XL. According to the 4.0 drivers, TMSRMN on an HPLASPS is equivalant to BoldItalicPS-1 on the NEC. Fat chance!) Comments? -- Mark D. Freeman (614) 262-3703 StrongPoint Systems, Inc. mdf@tut.cis.ohio-state.edu 2440 Medary Avenue ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!mdf Columbus, OH 43202-3014 Guest account at The Ohio State University
mjg@ecsvax.UUCP (Michael Gingell) (12/16/87)
In article <3204@tut.cis.ohio-state.edu>, mdf@tut.cis.ohio-state.edu (Mark D. Freeman) writes: > I just upgraded from 3.1 to 4.0. I use an Okidata Laser, and under 3.1 > I used the HPLASPS driver, as there wasn't an OKILASER driver yet. > > In switching over to the OKILASER driver, I noticed something rather > odd. The TMSRMN font was roman-a in one driver and roman-i (or some other > variant) in the other. This meant either modifying the OKILASER driver > to match the HPLASPS driver, or changing all my style sheets. > I noticed the same thing switching from version 2 to version 3. The printer definition file for the Cordata Laser Printer was changed with the addition of a number of new fonts. If I use the new file with a document prepared with the old file I get all the wrong fonts. It looks as if the document you write has embedded in it codes which tell Word to get the nth font from the start of the file - NOT a specific code for a style and size of font. I have ended up with retaining the old file and the new, and selecting whichever one is needed at print time. I am still waiting for my upgrade to 4.0. I fully expect to have to maintain 3 different definition files - and worse to have to remember which documents were prepared with which definition files. Mike Gingell ...decvax!mcnc!ecsvax!mjg
mdf@tut.cis.ohio-state.edu (Mark D. Freeman) (12/17/87)
In <4314@ecsvax.UUCP> mjg@ecsvax.UUCP (Michael Gingell) writes: >In article <3204@tut.cis.ohio-state.edu>, mdf@tut.cis.ohio-state.edu (Mark D. Freeman) writes: >> In switching over to the OKILASER driver, I noticed something rather >> odd. The TMSRMN font was roman-a in one driver and roman-i (or some other >> variant) in the other. This meant either modifying the OKILASER driver >> to match the HPLASPS driver, or changing all my style sheets. >I noticed the same thing switching from version 2 to version 3. The >printer definition file for the Cordata Laser Printer was changed with >the addition of a number of new fonts. If I use the new file with >a document prepared with the old file I get all the wrong fonts. It >looks as if the document you write has embedded in it codes which tell >Word to get the nth font from the start of the file - NOT a specific >code for a style and size of font. The document stores a Font Number. Font Numbers can be defined in any order in the PRD file. Font Numbers map to Font Type (roman, modern, etc.) and Number (a-?). >I have ended up with retaining the old file and the new, and selecting >whichever one is needed at print time. No need to do this. Do what I did. Use MAKEPRD to get a text file of both drivers. Pull them up in an editor and compare the Font Numbers associated with each FontName. Change the Numbers in the new driver to match the numbers in the old file for the same FontName. If you need more help on this, send email. I'd be happy to help out. -- Mark D. Freeman (614) 262-1418 mdf@tut.cis.ohio-state.edu 2440 Medary Avenue ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!mdf Columbus, OH 43202-3014 Guest account at The Ohio State University
johnl@ima.ISC.COM (John R. Levine) (12/17/87)
In article <3204@tut.cis.ohio-state.edu> mdf@tut.cis.ohio-state.edu (Mark D. Freeman) writes: >I just upgraded from 3.1 to 4.0. ... >In switching over to the OKILASER driver, I noticed something rather >odd. The TMSRMN font was roman-a in one driver and roman-i (or some other >variant) in the other. This meant either modifying the OKILASER driver >to match the HPLASPS driver, or changing all my style sheets. > >Is this a screw-up by Microsoft, or is there some good reason for this? It appears to me that Microsoft doesn't try very hard to put corresponding fonts in the same place for the descriptions of various printers, which as noted causes pain and suffering when trying to switch from one printer to another. Fortunately, it is very easy to use the MAKEPRD program to whip the printer descriptions into shape. First you run MAKEPRD to translate an offending PRD file into an editable text file. Then you edit the text file (probably not with Word) and change the font numbers. A line starting with "{F16" indicates the start of the modern a font, you could change this to "{F24" to make it the modern i font, or vice versa. Then use MAKEPRD again to translate your modified text file into a PRD file. There is lots of other obscure stuff in a PRD file, but fortunately you need not understand it to renumber the fonts. Having spent an hour or so doing this, you should end up with a set of PRD files that matches the fonts that you use in your style sheets, and the problem is solved, at least until the next update of Word. MAKEPRD is explained in detail in the Word Printer Information manual. -- John R. Levine, IECC, PO Box 349, Cambridge MA 02238-0349, +1 617 492 3869 { ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something The Iran-Contra affair: None of this would have happened if Ronald Reagan were still alive.
malloy@crash.cts.com (Sean Malloy) (12/18/87)
In article <3204@tut.cis.ohio-state.edu> mdf@tut.cis.ohio-state.edu (Mark D. Freeman) writes: >I just upgraded from 3.1 to 4.0. I use an Okidata Laser, and under 3.1 >I used the HPLASPS driver, as there wasn't an OKILASER driver yet. > > . . . (We also use a NEC >P5-XL. According to the 4.0 drivers, TMSRMN on an HPLASPS is >equivalant to BoldItalicPS-1 on the NEC. Fat chance!) > >Comments? > I recently got my Word 4.0 upgrade, and I found a number of subtly disturbing things in Word's drivers. I have an NEC CP6 printer, and have had to rework the driver Microsoft provides, due to the following set of annoyances: 1. The underline function works by underlining in Epson mode graphics -- at 120 dpi. The printer has a maximum resolution of 360dpi, but more importantly, it has a built-in underline function that was ignored. 2. The superscript and subscript functions use full-size characters shifted up or down by a half-line. Again, the CP6 has built-in superscript and subscript functions that use reduced size characters. 3. The default fonts are all draft mode on the CP6, and the draft/final switch in the Print Options menu doesn't seem to have any effect on the output. I'm more likely to do a NLQ printout than a draft printout, so why make the draft fonts the defaults? 4. Microspacing is again done using Epson graphics, this time at 240 dpi. 5. Double underlining is again done at 120 dpi using Epson graphics. Some of these I can't do anything about; Word _still_ doesn't know that 24-pin printers exist, so I can't tell Word to draw double underlines and to microspacing at 360 dpi. There are enough 24-pin printers on the market now that you'd expect Miscrosoft to take advantage of their capabilities -- all it would take is adding a flag to the 'mod' field of the PCSD to be defined as "24-pin graphics. 3 bytes of graphics data for each column of graphics printed." and modify the printer output routines accordingly. But no. That might have been useful. -- Sean Malloy {hplabs!hp-sdd, akgua, sdcsvax, nosc}!crash!malloy ARPA: crash!malloy@nosc Naval Personnel Research and Development Center San Diego, CA 92152-6800 UUCP: {hplabs!hp-sdd, akgua, sdcsvax}!nprdc!malloy ARPA: malloy@nprdc
cramer@optilink.UUCP (Clayton Cramer) (12/22/87)
> I recently got my Word 4.0 upgrade, and I found a number of subtly > disturbing things in Word's drivers. I have an NEC CP6 printer, and > have had to rework the driver Microsoft provides, due to the following > set of annoyances: > > 1. The underline function works by underlining in Epson mode graphics > -- at 120 dpi. The printer has a maximum resolution of 360dpi, but > more importantly, it has a built-in underline function that was > ignored. > The Epson LQ series driver that comes with Word has the same method of doing underlining -- but when I started fiddling with the PRD file to take advantage of the built-in underlining mode, I began to see why Microsoft decided to do underlining in graphics mode -- Epson underlining only works on printing characters. If you try to underline blanks, you don't get underlining. Now, I think this looks a lot nicer than underlining that goes under everything, but if you are trying to use underlining to draw a line across the bottom of an invoice (not an uncommon use of underlining), it doesn't work. You get something like: 25 hours @ $40/hour $1000.00 -- ----- - -------- -------- Total $9000.00 I've experimented a little with the underlining modes, and I still haven't found a set of modes to set in the PRD file for the Epson LQ series that gives me useful underlining and correct footnote dividers using the native underline mode. (Although it may be possible). Clayton E. Cramer