Re: Changing CPI now working in scs2pdf -- LINUX5250


On Tue, 19 Mar 2002, James Rich wrote:
>
> > > I'm also wondering if the fonts used and the sizes should be user
> > > selectable.  Right now you get Courier 10 point for 10 CPI, and Courier
> > > Bold for bold, Courier 8 point for 12 CPI, and Courier 6 point for 16 CPI.
> > > Maybe someone would like to use something besides Courier?  And maybe
> > > different point sizes?
> >
> > It seems to me that the best way would be to translate OS/400's output
> > to a corresponding font.   So, you can create a document on the iSeries,
> > get everything working there and send it to your PC to make a PDF.
>
> This is tricky.  The testing I've done only shows the CPI being sent if a
> document uses more than one CPI setting in the document.  But I'm sure my
> testing is incomplete because even if a document only uses 15 CPI
> throughout the printer must be told to do so.

Hmmm... I wonder if OS/400's print writer keeps track of the "current
state" of the printer?   It seems likely to me that it sends the control
codes to set things up only if it thinks that the printer's settings have
changed.

>
> But let's suppose that we get the initial CPI setting and it is 10 CPI.
> How do we translate that to a corresponding font?  Right now 10 CPI is
> hardcoded to be 10 point Courier because 10 point Courier fits on an
> 8.5x11 piece of paper about the same way that an 80 column, 10 CPI report
> fits on the same paper.  12 CPI is hardcoded to be a little smaller point
> size and 16 is a little smaller again.  Do we just make a map (like we
> basically have now) that says CPI x is equal to point size y?
>
> If we do make a map, suppose that someone doesn't like our choices for
> what point size goes with what CPI.  That leads to ...
>
> > It seems unlikely that someone would want to change their PC config
> > individually for every document that they want different features on.
>
> I meant the ability to choose fonts/size as in font_80 and font_132 in
> .tn5250rc.  Something like:
>
> host {
>       pdf_points_10cpi 13;
>       pdf_points_12cpi 10;
>       pdf_points_13cpi 9;
>       etc...
> }

You could do that, but please keep it consistent with the other config
options.   i.e., do it like:

host {
        pdf_points_10cpi = 13
        pdf_points_12cpi = 10
        pdf_ppoints_13cpi = 9
}

> > James, have you given any thought to how all your new printer code will
> > integrate with the Windows lp5250d?  Or have you thought about porting it
> > to the 0.16.x branch, so that it'll make it into the next release?  Or was
> > the plan to get it stable in the 0.17.x branch, and then port it after
> > it's stable?
>
> Short, honest answer: I haven't given it any thought.
>
> Truth is, I've never programmed a line of code on Windows.  I started
> working a little with mingw and the win32 port of glib over the weekend,
> but it doesn't seem to work right with NT.

I don't have an NT machine to test it on, so I don't know.  The docs for
the Windows API seem to imply that it would work on NT, though.  I've only
done it on Win95 & Win98.

If there's something wrong with NT support, we probably need to see if we
can fix that.

> I sort of thought that 0.16.x branch would become obsolete and if people
> wanted to use scs2pdf then they would have to get cvs from the trunk.

CVS is only for developers or people who want to help the developers with
testing, etc.

The mainstream releases are the tarballs.   The 0.17.x branch is not done
yet.  All of the python work needs to be completed, in addition to the GTK
work, which is waiting for Jay Felice to have time to work on it.

So, while 0.16.x will eventually be obsolete, the odds are that this won't
be any time soon.   Right now, it is the primary "stable" branch, and the
0.17.x is for new features that are still experimental.

What this amounts to, is that if you want your scs2pdf code to be
available to the majority of users, you need to make it work in the 0.16.x
branch.


> So I didn't think at all about porting until you mentioned that pipes in
> Windows really suck and that you had an alternate way of doing things.  I
> was going to search through the archives for the message where you
> explained your approach but I haven't gotten to it yet.  I'm hoping your
> approach is really easy...

I don't know if I posted anything in the archive.  It's just a
state-machine instead of reading from stdin.   Right now, scs2xxx
"takes control" by reading a byte from stdin, and depending on what
that byte is, it reads more from stdin, etc.

In the Windows version, I have a function like:  scs2ascii(printer, byte);
it gets called with each new byte retrieved from the AS/400.   What makes
this different from the scs2xxx programs is that it can't go back and
read more from the stream, it can only get its input from what's passed to
it. -- so it has to remember where it left off so it knows what the next
byte it's given will be used for...


>
> And I wouldn't feel bad if tn5250 and the associated software was the
> killer application that got everyone to stop using windows and switch to
> something better.

I simply can't imagine that Tn5250 having that big of an impact.
Especially when there's dozens of other 5250 emulators out there.   Having
an open source Tn5250 doesn't help/hurt the Windows community as a whole
-- but it's a big boon for the iSeries community.

> Hacking on windows (I'm finding out) is no fun, and I
> know supporting it isn't either.  I wouldn't mind if it just went away.

I like Unix better than Windows as well.   But, when I'm forced to use
Windows, I want a good 5250 client over there :)

> Of course that doesn't mean I'm going to write some function
> I_only_run_on_the_One_True_OS("Linux") either :)  I'll take a more serious
> look at the win32 directory now that it is in cvs HEAD.

That's good.  :)   Otherwise, I'll do it -- but then it has to wait in
line behind all of my other tasks.