[9fans] printing via local attached printer with gs driver

[9fans] printing via local attached printer with gs driver

[Gabriel Diaz]

Hello

has anyone a setup like this one working?

I have a line in the devices file like:

printer - - /dev/lpt1data - gs!ljet4 generic nosspol - - - -

but if i try man lp | lp -dprinter I got a gs suicide.

thanks

gabi

cpu% man lp | lp -dprinter
gs : suicide: sys: fp: invalid operation fppc=0xd52cd status=0xb8a1
pc=0x000d4fc8
cat: can't open /tmp/gsp26522: '/tmp/gsp26522' file does not exist
cpu% acid 26529
/proc/26529/text:386 plan 9 executable

/sys/lib/acid/port
/sys/lib/acid/386
acid: stk();
gs_screen_currentpoint(penum=0xdfffdbac,ppt=0xdfffdb70)+0x7f
/sys/src/cmd/gs/src/gshtscr.c:561
gx_ht_process_screen_memory(penum=0xdfffdbac,pgs=0x303b30,phsp=0x64f108,accurate=0x0,mem=0x2e7d04)+0x4c
/sys/src/cmd/gs/src/gsht.c:263
gs_sethalftone_prepare(pht=0x64f0bc,pgs=0x303b30,pdht=0x64f128)+0x252
/sys/src/cmd/gs/src/gsht1.c:201
zsetcolorscreen(i_ctx_p=0x31bbec)+0x1c8 /sys/src/cmd/gs/src/zht1.c:78
interp(pi_ctx_p=0x2e53a4,pref=0xdfffe0d0,perror_object=0xdfffe338)+0x898
/sys/src/cmd/gs/src/interp.c:1512
gs_call_interp(pref=0xdfffe314,pi_ctx_p=0x2e53a4,pexit_code=0xdfffe340,perror_object=0xdfffe338,user_errors=0x1)+0x105
/sys/src/cmd/gs/src/interp.c:488
gs_interpret(pi_ctx_p=0x2e53a4,perror_object=0xdfffe338,pref=0xdfffe314,user_errors=0x1,pexit_code=0xdfffe340)+0x59
/sys/src/cmd/gs/src/interp.c:446
gs_main_interpret(minst=0x2e51d0,pref=0xdfffe314,user_errors=0x1,pexit_code=0xdfffe340,perror_object=0xdfffe338)+0x45
/sys/src/cmd/gs/src/imain.c:214
gs_run_init_file(minst=0x2e51d0,pexit_code=0xdfffe340,perror_object=0xdfffe338)+0x12d
/sys/src/cmd/gs/src/imain.c:542
gs_main_init2(minst=0x2e51d0)+0xf1 /sys/src/cmd/gs/src/imain.c:352
swproc(pal=0xdfffe654,arg=0xdfffefc8,minst=0x2e51d0)+0x2e8
/sys/src/cmd/gs/src/imainarg.c:270
gs_main_init_with_args(argv=0xdfffef4c,argc=0x8,minst=0x2e51d0)+0x292
/sys/src/cmd/gs/src/imainarg.c:207
main(argc=0x8,argv=0xdfffef4c)+0x3b /sys/src/cmd/gs/src/gs.c:47
_main+0x26 /sys/src/ape/lib/ap/386/main9.s:12
acid: acid:

Re: [9fans] printing via local attached printer with gs driver

[Russ Cox]

Did you compile your own copy of ghostscript?
This is a common problem if you compile directly
from the gs sources; there are some Plan 9 specific
changes that must be made.  See /sys/src/cmd/gs/mkfile:

# If you get weird floating point errors, the culprit is usually the
# halftone code, which converts double to uint, something 8c handles
# incorrectly (treats as double to int).  Look in src/gshtscr.c for a line like
#
# 	sample = (ht_sample_t)((value+1) * max_ht_sample);
#
# and change it to one of:
#
# 	sample = (int)(vlong)((value+1) * max_ht_sample);
#	sample = (ht_sample_t)(value * max_ht_sample) + max_ht_sample;
#
# depending on your preference.
#
# Also, recent versions of src/gxshade1.c cause the compiler to run out
# of registers.  Brucee is looking into this.  In the meantime, use this
# replacement:
#
#	private inline void
#	make_other_poles(patch_curve_t curve[4])
#	{
#	    int i, j;
#
#	    for (i = 0; i < 4; i++) {
#		j = (i + 1) % 4;
#		curve[i].control[0].x = (curve[i].vertex.p.x * 2 + curve[j].vertex.p.x);
#		curve[i].control[0].x /= 3;
#		curve[i].control[0].y = (curve[i].vertex.p.y * 2 + curve[j].vertex.p.y);
#		curve[i].control[0].y /= 3;
#		curve[i].control[1].x = (curve[i].vertex.p.x + curve[j].vertex.p.x * 2);
#		curve[i].control[1].y /= 3;
#		curve[i].control[1].y = (curve[i].vertex.p.y + curve[j].vertex.p.y * 2);
#		curve[i].control[1].y /= 3;
#		curve[i].straight = true;
#	    }
#	}
#
# (the original includes the /3 in the big expressions).

The source in the distribution should be patched already.
Also I thought I fixed 8c to do the right float -> uint
conversion, but it would have been quite a while ago
and I don't remember.

Russ

Re: [9fans] printing via local attached printer with gs driver

[Gabriel Diaz]

hello

No, I just used the CD of May 12.  should i recompile gs and see what happens?

thanks

gabi


On 6/18/07, Russ Cox <rsc@swtch.com> wrote:
> Did you compile your own copy of ghostscript?
> This is a common problem if you compile directly
> from the gs sources; there are some Plan 9 specific
> changes that must be made.  See /sys/src/cmd/gs/mkfile:
>
> # If you get weird floating point errors, the culprit is usually the
> # halftone code, which converts double to uint, something 8c handles
> # incorrectly (treats as double to int).  Look in src/gshtscr.c for a line like
> #
> #       sample = (ht_sample_t)((value+1) * max_ht_sample);
> #
> # and change it to one of:
> #
> #       sample = (int)(vlong)((value+1) * max_ht_sample);
> #       sample = (ht_sample_t)(value * max_ht_sample) + max_ht_sample;
> #
> # depending on your preference.
> #
> # Also, recent versions of src/gxshade1.c cause the compiler to run out
> # of registers.  Brucee is looking into this.  In the meantime, use this
> # replacement:
> #
> #       private inline void
> #       make_other_poles(patch_curve_t curve[4])
> #       {
> #           int i, j;
> #
> #           for (i = 0; i < 4; i++) {
> #               j = (i + 1) % 4;
> #               curve[i].control[0].x = (curve[i].vertex.p.x * 2 + curve[j].vertex.p.x);
> #               curve[i].control[0].x /= 3;
> #               curve[i].control[0].y = (curve[i].vertex.p.y * 2 + curve[j].vertex.p.y);
> #               curve[i].control[0].y /= 3;
> #               curve[i].control[1].x = (curve[i].vertex.p.x + curve[j].vertex.p.x * 2);
> #               curve[i].control[1].y /= 3;
> #               curve[i].control[1].y = (curve[i].vertex.p.y + curve[j].vertex.p.y * 2);
> #               curve[i].control[1].y /= 3;
> #               curve[i].straight = true;
> #           }
> #       }
> #
> # (the original includes the /3 in the big expressions).
>
> The source in the distribution should be patched already.
> Also I thought I fixed 8c to do the right float -> uint
> conversion, but it would have been quite a while ago
> and I don't remember.
>
> Russ
>
>

Re: [9fans] printing via local attached printer with gs driver

[Gabriel Diaz]

hello

I recompiled taking this in account, but the problem persists (the
src/gshtscr.c has a sightly different line in the distribution than in
the mkfile, so i changed it to the one of mkfile )

Also sources already have the make_other_poles function patched.

thanks

gabi


On 6/18/07, Russ Cox <rsc@swtch.com> wrote:
> Did you compile your own copy of ghostscript?
> This is a common problem if you compile directly
> from the gs sources; there are some Plan 9 specific
> changes that must be made.  See /sys/src/cmd/gs/mkfile:
>
> # If you get weird floating point errors, the culprit is usually the
> # halftone code, which converts double to uint, something 8c handles
> # incorrectly (treats as double to int).  Look in src/gshtscr.c for a line like
> #
> #       sample = (ht_sample_t)((value+1) * max_ht_sample);
> #
> # and change it to one of:
> #
> #       sample = (int)(vlong)((value+1) * max_ht_sample);
> #       sample = (ht_sample_t)(value * max_ht_sample) + max_ht_sample;
> #
> # depending on your preference.
> #
> # Also, recent versions of src/gxshade1.c cause the compiler to run out
> # of registers.  Brucee is looking into this.  In the meantime, use this
> # replacement:
> #
> #       private inline void
> #       make_other_poles(patch_curve_t curve[4])
> #       {
> #           int i, j;
> #
> #           for (i = 0; i < 4; i++) {
> #               j = (i + 1) % 4;
> #               curve[i].control[0].x = (curve[i].vertex.p.x * 2 + curve[j].vertex.p.x);
> #               curve[i].control[0].x /= 3;
> #               curve[i].control[0].y = (curve[i].vertex.p.y * 2 + curve[j].vertex.p.y);
> #               curve[i].control[0].y /= 3;
> #               curve[i].control[1].x = (curve[i].vertex.p.x + curve[j].vertex.p.x * 2);
> #               curve[i].control[1].y /= 3;
> #               curve[i].control[1].y = (curve[i].vertex.p.y + curve[j].vertex.p.y * 2);
> #               curve[i].control[1].y /= 3;
> #               curve[i].straight = true;
> #           }
> #       }
> #
> # (the original includes the /3 in the big expressions).
>
> The source in the distribution should be patched already.
> Also I thought I fixed 8c to do the right float -> uint
> conversion, but it would have been quite a while ago
> and I don't remember.
>
> Russ
>
>