Conference 7.286::postscript_printing

re:         <<< Note 7147.0 by 52445::CHAIM "Semper ubi Sub ubi ....." >>>
>                    -< Colorwriter LSR 2000 - what protocols >-
> 
> LSR2000
> 
    The LSR2000 is a Level 2 PostScript printer and should
    be able to print a PostScript document containing
    Hebrew fonts. My recommendation is that you should
    go with the LSR2000+ as it has a better font
    implementation.

    /Bob Anderson

Bob,

Thanks very much for the reply.


>> LSR2000
>> 
>    The LSR2000 is a Level 2 PostScript printer and should
>    be able to print a PostScript document containing
>    Hebrew fonts. My recommendation is that you should
>    go with the LSR2000+ as it has a better font
>    implementation.
>

The problem is not printing PostECript documents which contain Hebrew fonts as
these shou;d print without any problems. 

The problem is printing ASCII text which contains Hebrew characters. With all
the previous printers (LPS17/20/32 and DECLASER 1150/2150/2250/2500/5100) the
only way such files could be printed was printing them using DCPS via the ANSI
translator and at the same time downloading a Hebrew font and a Hebrew setup
file. 

So, if the LSR 2000/2000+ doesn't support LAT protocol then it will be a
problem printing Hebrew ASCII text files until V1.4 is Hebrewized, which due to
special circumstances may never happen.

Thanks,

Cb.

DCPS V1.4 will *NOT* improve the Colorwriter LSR 2000[+] connectivity.

The only IP protocol that the LSR 2000 supports is LPD.  DCPS V1.4 will
not support LPD, but rather "raw TCP/IP".

DCPS also requires bidirectional support.  I tried connecting a
Rapidprint 500 to the LSR 2000's parallel port, but the latter is not
bidirectional.

So... if you want to use DCPS with the LSR 2000, you must use AppleTalk.

						--Dan S.

RE: .0

> 3.	The network card support AppleTalk, but this would requier a DCPS-OPEN
> 	license and is supported only in V1.3.

Use of AppleTalk does *NOT* require the DCPS-OPEN license.  It's the use of
a third-party printer that requires the open license.

BUT, the customer would have to obtain AppleTalk for OpenVMS to get the
network support.

AND, the LNC01 is only supported in DCPS V1.3, regardless of the connectivity.
This would be true even for LAT, if it were supported for the LNC01.  I don't
understand the point of your last phrase above.

						--Dan S.

>Use of AppleTalk does *NOT* require the DCPS-OPEN license.  It's the use of
>a third-party printer that requires the open license.
>

I must have been mistaken, but I thought that I had seen this requirement
mentioned in a previous note regarding the LSR200 printer.


>AND, the LNC01 is only supported in DCPS V1.3, regardless of the connectivity.
>This would be true even for LAT, if it were supported for the LNC01.  I don't
>understand the point of your last phrase above.

My point is that due to an unfortunate situation we are currently quagmired at
V1.2 since this is the last version for which a Hebrew option was developed
(locally). I am attempting to get the local engineering group to develop a
Hebrew option for V1.4 before the group is disbanded, but I don'y know if my
efforts will bear any fruit.

Thanks,

Cb.

Hello,

	You have said about Hebrew option being supported up until
	DCPS V1.2. How is this option provided ?  Without the
	availability of DCPS sources I would imagine setup libraries/
	fonts as the means of adding this feature.  If this is the
	approach you have taken then it should work even in DCPS V1.3.

	Have you taken any other approach to provide the Hebrew option,
	if so how ?

-Harish Kamath. 

>
>        You have said about Hebrew option being supported up until
>        DCPS V1.2. How is this option provided ?  Without the
>        availability of DCPS sources I would imagine setup libraries/
>        fonts as the means of adding this feature.  If this is the
>        approach you have taken then it should work even in DCPS V1.3.
>
	
You are partially correct with your evaluation of how the Hebrew support has
been implemented. Most of it is done through PostScript library modules and
fonts. However, the trn$ansi_ps.exe file also has been modified via the PATCH
utility. Up until V1.2 the modification in trn$ansi_ps.exe was merely to "zap"
the character tables for the character with decimal value 240, which otherwise
printed as an inverted question mark. In V1.2 another modification was required
for the LPS17/600, but I don't know exactly what this entailed. I do know that
it was not implemented at source code level but rather using the PATCH utility.

So, basically (barring the unexpected) for any subsequent version of DCPS after
V1.2 the Hebrew option should still work as long as the TRN$ANSI_PS.EXE image
has not been modified.

Could you please tell me if this is so for V1.3 and V1.4.

>        Have you taken any other approach to provide the Hebrew option,
>        if so how ?
>

Not yet. I have been in contact with the DCPS product manager, but due to the
unclear futures of DCPS we were unable to get anywhere.

I do believe that it would probably be more advisable to implement the Hebrew
in a more elegant manner and one which would be generic and more transparent as
well as more easily supported.

Thanks,

Cb.

Hello,

	Okay, now I understand how this support is being provided.

	There have been no changes to the DCPS translators in V1.3
	release.  This release contained mostly support for new
	printers and some bug fixes to the symbiont.  There were
	no changes made to the translators.

	DCPS T1.4 symbiont is built with DEC-C compiler, this required
        us to rebuild all the translators with DEC-C.  We might have
        done a few very minimal changes to the ANSI translator code
	when converting to DEC-C from VAX-C.  Any changes made were
	mostly related to porting issues.

	I had rebuilt all the translators and this was sometime mid
	of 1996.

Regards,

-Harish Kamath.

RE: .8

The LIST translator was changed in DCPS V1.3, to darken the gray background
bars for some printers.

						--Dan S.