× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




On Mon, 11 Mar 2002, James Rich wrote:

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

I'll follow suit, then.

>
> > 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.

No, I think the x,y coordinates do determine where it's placed...  Thats
why it's able to skip spaces in the text, and it's how ahpp works in
scs2ps.

> > 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.
>
> 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.

If you look a little closer at scs2ps, I see a line in scs2ps_ahpp()
that looks like this:
      ccp = fgetc(stdin);

It appears to me that it's setting the next horizontal character position
directly by reading it from the file.  (Which is very different from the
way scs2ascii deals with it, scs2ascii inserts spaces)

> 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.

Nope, scs2ps does fine with joblogs...

> 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.

I've been using scs2ascii quite extensively for a very long time.  I feel
confident that it works well.   I don't know if it's more "complete", but
I don't really think it needs to be, since it's basically dropping all
special formatting, and making a plain ascii file.

> 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.

Once the bugs are gone, yes :)



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.