jon@jonlab.UUCP (Jon H. LaBadie) (10/09/90)
If I'm so novice here, I apologize.
I recently acquired a laser printer (Texas Instruments) that is
both HP II and PostScript compatible.
For most of my text processing I use troff. I have DWB II for my
computer and JetRoff shareware for printing in HP mode. However,
I would like to do some of the fancier things available in PS.
Thus, two questions:
1. What troff -> PostScript converters are available? Note, I
am using an AT&T 3B1, so probably there is not much commercial
software for this system.
2. Given that I am using a stock troff (ditroff), how do I reference
the myriad fonts available with PS using the 2 character limits
in troff?
Thanks for your help,
Jon
--
Jon LaBadie
{att, princeton, bcr, attmail!auxnj}!jonlab!jonhenry@angel.Eng.Sun.COM (Henry McGilton) (10/10/90)
In article <864@jonlab.UUCP>, jon@jonlab.UUCP (Jon H. LaBadie) writes:
* I recently acquired a laser printer (Texas Instruments)
* that is both HP II and PostScript compatible.
* For most of my text processing I use troff. I have DWB
* II for my computer and JetRoff shareware for printing
* in HP mode. However, I would like to do some of the
* fancier things available in PS.
* Thus, two questions:
1. What troff -> PostScript converters are available? Note, I
am using an AT&T 3B1, so probably there is not much commercial
software for this system.
TranScript is available from Adobe Systems. DevPS is available
from Pipeline Associates.
2. Given that I am using a stock troff (ditroff), how do I reference
the myriad fonts available with PS using the 2 character limits
in troff?
You can change ditroff to support more than ten fonts. The
changes are relatively easy, involving a change to a number
in a header file. You also must change the setfont
routines in ditroff to make the \f sequence and the .ft
request process numbers greater than nine. You also need
to change makedev. If you get TranScript, you need to
recompile psdit for the same number of fonts as well. If
you have devps, you need to change a define in
stuff.h. In my installation it's already set to 25.
The two character limit on font names is pretty pervasive
in troff and very hard to change easily. There have been
various guidelines posted in the past as to how to map
font names to troff cryptic names.
........ Henryclewis@ecicrl.UUCP (Chris Lewis) (10/12/90)
In article <864@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes: > 1. What troff -> PostScript converters are available? Note, I > am using an AT&T 3B1, so probably there is not much commercial > software for this system. tpscript aka ditroff2ps was posted on comp.sources.unix a few years ago and will do what you want. > 2. Given that I am using a stock troff (ditroff), how do I reference > the myriad fonts available with PS using the 2 character limits > in troff? ditroff -> Postscript converters have tables in them that map the 2 character troff name into the real Postscript name. tpscript already comes configured for most of the fonts you can get from an Apple LaserWriter, plus tools to build the width tables for fonts that it doesn't already know about. -- Chris Lewis, Phone: TBA UUCP: uunet!utai!lsuc!ecicrl!clewis Moderator of the Ferret Mailing List (ferret-request@eci386) Psroff mailing list (psroff-request@eci386)
brad@ds3 (Bradley E. Smith) (10/12/90)
I am using the tpscript program and having problems with characters not lining up. Is anyone out there else using it? Could someone try my file? Also does anyone know where one can get a book describing the postscript lang.? thanks brad smith brad@bradley.edu
clewis@ecicrl.UUCP (Chris Lewis) (10/15/90)
In article <1990Oct12.163552.8448@bradley2.bradley.edu> brad@ds3 (Bradley E. Smith) writes: >I am using the tpscript program and having problems with characters >not lining up. Is anyone out there else using it? Could someone >try my file? What do you mean by characters "not lining up"? Does it look as if troff is getting the widths of the characters wrong? If so, either you've not built/installed the width tables correctly, or the width tables themselves are wrong. Look into the R, I, B etc. files, make sure that they're being processed properly by makedev, and installed. On the other hand, it could be that the widths are wrong. It could be that tpscript isn't selecting the font that it thinks it is, or that your printer has a different font set. There are postscript programs in the tpscript release that you can download to get the character widths regenerated. -- Chris Lewis, Phone: TBA UUCP: uunet!utai!lsuc!ecicrl!clewis Moderator of the Ferret Mailing List (ferret-request@eci386) Psroff mailing list (psroff-request@eci386)
brad@ds3.bradley.edu (Bradley E. Smith) (10/16/90)
clewis@ecicrl.UUCP (Chris Lewis) writes: >What do you mean by characters "not lining up"? Does it look as if >troff is getting the widths of the characters wrong? If so, either >you've not built/installed the width tables correctly, or the width >tables themselves are wrong. Look into the R, I, B etc. files, make >sure that they're being processed properly by makedev, and installed. Well to make a long story shorter. I have two packages that take ditroff and make postscript. One no source and one with source (which is tpscript). Since we are moving off our VAX to a SUN and don't won't to purchase someones own troff, I wanted to get tpscript working on the SUN. By using the same ditroff output, the 2 programs produced different results (tpscript being wrong). Below is a test file which failed. What would fail is the column of numbers would not line up straight. ====cut here replacing ^I with tabs .po 1i .sp 1i .nf .ta 3i .tc . .ps 7 .vs 8 .sp CHM 201 General Chemistry^I4 EFE 101 English Composition^I3 COM 105 Business & Professional Speech^I2 EE 102 Computational Techniques for EE^I2 MTH 122 Unified Calculus II^I4 PHY 110 University Physics I^I4 EE 201 Digital Hardware Organization^I2 EE 205 Fundamentals of Circuit Analysis^I4 MTH 223 Unified Calculus III^I4 PHY 201 University Physics II^I4 ====== How I fixed is as follows tpscript sends an horp position then a word. Each word being in a 'NNNN X (text_here)s'. The tab fill char, which is a '.' would be put altogether ( "NNNN X (......)s" ). What I changed tpscript to do is to send out "NNNN X (.)s" for each character that is not "a-z" or "A-Z". This increased the size of the output but it worked. The fonts and DESC are the ones that came with tpscript, and another program using the same output works. So I felt the problem was and is with tpscript. One a side note I looked at the postscript output and couldn't find anything wrong with it (all the X positions added up right). The only thing I can think is that the character '.' is narrower than the font table. But if this is so then why didn't the other program have a problem? If anyone could try the above example using tpscript I would love hearing from you. brad smith brad@bradley.edu
clewis@ecicrl.UUCP (Chris Lewis) (10/18/90)
In article <1990Oct16.145303.20446@bradley2.bradley.edu> brad@ds3.bradley.edu (Bradley E. Smith) writes: |clewis@ecicrl.UUCP (Chris Lewis) writes: |Well to make a long story shorter. I have two packages that take |ditroff and make postscript. |... By using the same ditroff output, the 2 programs |produced different results (tpscript being wrong). |... What would fail is the column of numbers would not line up straight [using "." as leader] |tpscript sends an horp position then a word. Each word being |in a 'NNNN X (text_here)s'. The tab fill char, which is a '.' |would be put altogether ( "NNNN X (......)s" ). What I changed |tpscript to do is to send out "NNNN X (.)s" for each character that |is not "a-z" or "A-Z". This increased the size of the output but |it worked. |The fonts and DESC are the ones that came with tpscript, and another |program using the same output works. So I felt the problem was and |is with tpscript. |One a side note I looked at the postscript output and couldn't find |anything wrong with it (all the X positions added up right). The |only thing I can think is that the character '.' is narrower than |the font table. But if this is so then why didn't the other program |have a problem? There's two possibilities: 1) the width table is truly wrong by a bit. If the other program doesn't do as complete a job of coalescing characters into single show commands, (even to the extent of drawing each character separately), the error in the width table would accumulate in the case of tpscript, but perhaps not in the other package. I seem to remember tpscript generating relative moves. 2) Tpscript has an internal width truncation problem. I had both problems when I introduced this kind of optimization into psroff - I needed to round-off the numbers in the width tables when I scaled them to CAT-style width tables. In long words, the cumulative effect could have words overlap - the word started at the proper place, but the word was longer or shorter than CAT troff thought when drawn using the engine's width tables as opposed to the width tables generated by tpscript's postscript program and then scaled to CAT widths. Without the optimizer, this didn't matter - because each character was shown separately using absolute X positions, and the error didn't accumulate to something brutally obvious. (after the fact, I discovered that it was barely visible even between single characters). Once I carefully rounded off the scaling, it worked perfectly. The second problem was truncation in the calculation of X-position after each character was added to an accumulated string. Sometimes the calculation got far enough to terminate the string accumulation (degradation of optimization, not accuracy). I've used tpscript but haven't noticed this problem before. I'll send your example off to someone who has current access to a tpscript configuration (actually, CAT troff | psroff | tpscript). -- Chris Lewis, Phone: TBA UUCP: uunet!utai!lsuc!ecicrl!clewis Moderator of the Ferret Mailing List (ferret-request@eci386) Psroff mailing list (psroff-request@eci386)
clewis@ecicrl.UUCP (Chris Lewis) (10/23/90)
In article <1990Oct16.145303.20446@bradley2.bradley.edu> brad@ds3.bradley.edu (Bradley E. Smith) writes: >What would fail is the column of numbers would >not line up straight. [ with tpscript using periods as a leader ] For your information: Greg Woods sent this to me in reply to my request that he test your sample: |[ On Thu Oct 18 12:56 (Re: "Could you test this sample for me?"), I wrote: ] |> Please run the sample troff in this posting through psroff, with no "-T", |> "-Tops" and "-Ttps" - eg: default, optimized and tpscript. Let me know |> if the columns don't line up. | |Noope, they don't all work. However, the interesting thing is this: |the default, no-optim. version, works fine. The other two have [unoptimized CAT troff -> postscript worked, optimized CAT troff -> postscript, and CAT troff -> ditroff -> tpscript didn't.] |identical behavior, i.e. they don't work. | |So, I tried each test with the tab character set to ' ', '_', and '.', |since I've never had any trouble with spaces and underscores any other |time. |The result is that what troff expects a string of dot's to display as, |and what PostScript actually does with them, is different. The spaces |and underscores actually do work fine in all cases, but only the |no-optim version, where troff is explicitly placing each period, do |the columns line up. |The text, on the other hand, seems to always line up perfectly (in the |"see-through" test). It seems PostScript knows no more about ligatures |and kerning than troff does when troff's ligatures are turned off, |execpt when it comes to periods! It's one of two things then, either the width table entry for periods is wrong (postscript width differs from the R table), or postscript is doing something funny with them. Unoptimized psroff->postscript (and I imagine the other package you tried) places each period individually, so the postscript widths don't matter. You might want to try rerunning the postscript program that comes with tpscript to see if it gets the widths any different. Or, twiddle manually. Or, modify tpscript to not optimize runs of periods (don't do the latter unless you really have to). -- Chris Lewis, Phone: TBA UUCP: uunet!utai!lsuc!ecicrl!clewis Moderator of the Ferret Mailing List (ferret-request@eci386) Psroff mailing list (psroff-request@eci386)
brad@ds3.bradley.edu (Bradley E. Smith) (10/23/90)
clewis@ecicrl.UUCP (Chris Lewis) writes: >|[ On Thu Oct 18 12:56 (Re: "Could you test this sample for me?"), I wrote: ] >|> Please run the sample troff in this posting through psroff, with no "-T", >|> "-Tops" and "-Ttps" - eg: default, optimized and tpscript. Let me know >|> if the columns don't line up. >| >|Noope, they don't all work. However, the interesting thing is this: >|the default, no-optim. version, works fine. The other two have >[unoptimized CAT troff -> postscript worked, optimized CAT troff -> >postscript, and CAT troff -> ditroff -> tpscript didn't.] >|identical behavior, i.e. they don't work. Thank you for confirming this. I just wasn't going crazy. >|The result is that what troff expects a string of dot's to display as, >|and what PostScript actually does with them, is different. The spaces >|and underscores actually do work fine in all cases, but only the >|no-optim version, where troff is explicitly placing each period, do >|the columns line up. I changed tpscript to output this way and I also see that it works. >You might want to try rerunning the postscript program that comes with >tpscript to see if it gets the widths any different. Or, twiddle manually. >Or, modify tpscript to not optimize runs of periods (don't do the latter >unless you really have to). I used the font tables that came with tpscript. So unless they were put in wrong (which they weren't because the other program works) I think it might be tpscript. I just got a postscript book on the language and will be looking at it. The program that doesn't run on our machine does send the '.......' altogether. Interesting problem. On a different note, I tried to send mail to the author and got no response. Is someone out there keeping this program up to date as far as things like this are conserned? Is this something that should be fixed? Brad Smith Bradley University brad@bradley.edu
clewis@ecicrl.UUCP (Chris Lewis) (10/26/90)
In article <1990Oct23.132755.18431@bradley2.bradley.edu> brad@ds3.bradley.edu (Bradley E. Smith) writes: >>You might want to try rerunning the postscript program that comes with >>tpscript to see if it gets the widths any different. Or, twiddle manually. >>Or, modify tpscript to not optimize runs of periods (don't do the latter >>unless you really have to). >I used the font tables that came with tpscript. So unless they were put >in wrong (which they weren't because the other program works) I think >it might be tpscript. I just got a postscript book on the language and >will be looking at it. The program that doesn't run on our machine does >send the '.......' altogether. Interesting problem. Postscript printers (and their resident fonts) differ, so it's usually a good idea to redo the width tables from what was distributed. On a related note, I got a message from Liam Quin where he noted that periods in odd-sized Courier fonts have "fractional widths", (by which I think he means that they aren't integers in the ditroff width tables), and they have to disable their optimizer in such circumstances, otherwise, troff thought a long string of dots was considerably narrower than the printer did, and subsequent stuff (though placed correctly) would overlap the last few dots. Any [di]troff-based driver for Postscript might have these problems because it's really difficult to tell whether the true widths (after scaling to various sizes) varies from the integer you're able to specify in the width tables. At least in ditroff you can adjust the resolution they're at and adjust all of the widths accordingly. In psroff (CAT troff-based), I'm stuck with "size of 6 point character in 1/432'nds. A scaleing that uses truncation can cause severe munging whereas roundoff doesn't. >On a different note, I tried to send mail to the author and got no >response. Is someone out there keeping this program up to date as >far as things like this are conserned? Is this something that should >be fixed? Not as far as I know. There are a number of things that could be tweaked in tpscript to get slight improvements, you might want to try some of the secondary authors. -- Chris Lewis, Phone: TBA UUCP: uunet!utai!lsuc!ecicrl!clewis Moderator of the Ferret Mailing List (ferret-request@eci386) Psroff mailing list (psroff-request@eci386)