Re: scs2ps -- LINUX5250

Cc'ed to linux5250@midrange.com since Tony can't seem to send for some
reason.

On Mon, 11 Mar 2002, Tony A. Lambley wrote:

> I've been looking at the source of scs2ps.  It doesn't look like too much
> effort to get it to print text that'll convert to searchable pdfs from
> scs2pdf, but I've never cut any C, so could be talking out of my bottom.

[snip]

> Using my absolute zero knowledge of C, I'd say it's processing each char from
> stdin, doing the control char stuff otherwise treats it as a character. If
> the latter, the character is passed with its x,y co-ords to the postscript
> procedure `s' which has already been written to the output by
> scs2ps_jobheader().

Pretty much, yes.  But the x,y coordinates have nothing to do with where
the print specifies that they should be placed.  Rather variable ccp (x
coordinate) just gets incremented each time a character is printed.
Whenever a new line character is encountered the y coordinates are
adjusted.

> I think to fix the problem, the `default' clause of the switch/case thingy
> should build a string until a newline is reached, and then printed as the
> current chars are now with the x-pos fixed.

This is basically how scs2pdf does things, except that Adobe recommends
that strings not be longer than 255 bytes, so we flush our buffer on new
line or when the buffer fills.

We also honor the AHPP code which horizontally positions the printer.
This fixed the problems with printing job logs.  scs2ps doesn't handle
that, but (I think) scs2ascii does.

> The issues will then be the changes needed to the control char routines (when
> to print the string being built), and possibly setting the fonts. The output
> won't be spreadout like the output James sent me, they'll be, well, normal
> (which may not looks as nice to some). There may be a way to set spacing
> within postscript, but I can't recall ever seeing it in my limited usage of
> postscript. I'll look it up tomorrow. Would be much easier to use a bigger
> point size!
>
> A fixed pitch font will be a must for cosmetics, the current process will let
> you get away with sans-serif characters, even though its currently set to
> use courier. The characters are currently using the postscript `standard'
> encoding not iso-8859-1. Might make a difference for the umlauts etc.

I've mentioned all these issues as things to work with for scs2pdf, too.
None of these are probably going to be very hard.

> I'd have a go, but it could take awhile learning the C instructions as I need
> them, and I don't know what the control chars are supposed to be doing -
> thanks to the lack of comments. Most seem to get dropped or used as errors.
> Do all C programmers use so little inline documentation as scs2ps?

Documentation?  What's that?  :)  If you are looking for all kinds of
comments my stuff in scs2pdf.c isn't much better.

> If there's more urgency, if you can get a string from the scs input, you'll
> have done 95+% of the work. I'll help where I can, but it might be painful
> with me on being on GMT!

You've already helped!  After reviewing scs2ps, I think scs2pdf might give
better results at this point.  You could really help by finding cases
where scs2pdf doesn't do the right thing.  And then compare that to
scs2ps.  I'll bet that scs2ps produces misformatted job logs.

Quite honestly I think that scs2pdf at this point is more complete than
scs2ps.  Both need testing and comparing.  I think scs2pdf is more
complete than scs2ascii, too.  Right now the best thing about scs2ps is
that I can pipe it straight to the postscript printer.  But I believe that
scs2pdf will give more accurate printouts.

James Rich
james@eaerich.com