24824 - [ps] Hebrew text prints as gibberish

Status: RESOLVED FIXED

(Core :: Printing: Output, defect, P3)

Description

[moshev]

You need to have hebrew fonts on your font server to see this.
LPR version 0.48
HP-4000 printer on SMB network.

1. Go to www.netvision.net.il
2. Change character set to hebrew-windows1255
3. You should now see the page in (reversed) hebrew.
4. Do File/Print and print the page.

Result: The page comes out with gibberish (latin with '', etc) instead
of hebrew.
Expected: Hebrew characters printed.


Some analysis:
	I believe this problem is common to hebrew printing using postscript.
	The resulting .ps file is attached

Comment 1

[moshev]

Attachment: The resulting netscape.ps file.

Comment 2

[dcone (gone)]

In order to print out postscript hebrew characters.. the hebrew AFM (Adobe 
Font Metrics) file appropriate for that font has to be installed.. or 
accessible.  Otherwise it will default to the default AFM files.  I am not sure 
where to go from here.. or how to resolve this bug.

Comment 3

[moshev]

The problem is not so much that the font is missing, but
the fact that the resulting postscript output contains 
the "Latin-1" encoding in it. How a hebrew text can be treated as Latin-1?
If the font is not available, it should not print, or should render 
the output as EPS, the same as "print true type as bitmap" setting in windows.
but in no way should it put a "Latin-1" patch inside postscript output when the
font can not be found. 
Does it even look for it?, or does it just puts Latin-1 always as the encoding?

Comment 4

[moshev]

To continue on my previous comment; take http://www.walla.co.il for example
The page is rendered with hebrew fonts, and the charset is recognized as 
iso-8859-8, however printing to file produces the file which i will attach.
The problem is that this whole .ps file is marked as isolatin1 
and %mozilla-charset iso-8859-1. 
This file also is not viewable in ghostview due to postscript errors.

Comment 5

[moshev]

Attachment: The output ps file

Comment 6

[Frank Tang]

dcone- you are the PostScript module owner, right ? Do you need help from i18n 
group to fix Unicode PostScript printing ?

Add several mozilla developer who interest about linux printing and bi-di to the 
cc list.

Comment 7

[Roland Mainz]

Maybe Xprt (X print server) can help here. Comments ?

Comment 8

[moshev]

Why M18? Any explanation why international printing
is not important enough?

Comment 9

[moshev]

Hmm, as a good answer to my previous question someone
changes this to M26?!!! 
I will ask again, international printing is not a requirement
in the only browser available to non windows users throughout the world?

Comment 10

[bobj]

Cc'ing the folks working on the Xprint implementation for comments.
See also bug 6312 "Linux: internationalize printing", but the real discussions
are currently in news:netscape.public.mozilla.i18n

Comment 11

[dcone (gone)]

This bug has been marked future because we have determined that it is not 
critical for netscape 6.0.  If you feel this is an error, or if it blocks your 
work in some way -- please attach your concern to the bug for reconsideration.

Comment 12

[moshev]

May i ask what is not important for NS6.0? 
Is it international printing, or international printing on Linux?
How about platform parity?
Or is it specifically printing Hebrew on Linux that is not important?
Is NS6.0 aimed at english users only?

Comment 13

[Hidetoshi Tajima]

Not to mention, international printing support is important, so there are
discussion
in mozilla-i18n newsgroup about this feature. Please look for the posts done
under the
subject
 "native encoding Font support in CJK PS printing"
and the proposed patch at,
http://village.infoweb.ne.jp/~katakai/mozilla/printing.htm.
This is under [e-mail]'s review. It will be checked in once he gives
us the GO
and we can get check-in approval from CVS gatekeeper.

Comment 14

[moshev]

<comment>
	Please excuse me if this comment is written in harsh tone
	and if it hurts anyone.
</comment>

What is was so upset about was dcone's comment saying 
<qoute>
This bug has been marked future because we have determined that it is not 
critical for netscape 6.0
</quote>
Ha?! Netscape 6.0? not a particular beta but the actual NS 6.0 release 
will only print english?
now read the page at http://village.infoweb.ne.jp/~katakai/mozilla/printing.htm
and i don't get how on earth was it not done this way from the start?
I've been talking (yes i know talk is cheap) about this for may be as long
as a year, that a user expects for an output Postscript to be in his native 
encoding and deal with lack of ghostscript fonts later and not be forced into
some arbitrary chosen iso-8859-1 encoding, which has nothing to do with the
original content of the web page.

Now if dcone (sorry, i don't know your real name) is responsible for giving you
the green light to include this in the regular builds, we (all international
users) are out of luck, cause he thinks that it is not important for NS 6.0.

There is only ONE reason that it may be not important for NS 6.0 and it is  that
Netscape as a company does not see platforms other than windows as important 
enough to go into trouble of providing descent internationalization for.

What's worse than that, is that <i>mozilla</i> as a project is influenced by a
purely marketing oriented decision such as this, and completely disregards 
non windows users on all non-trivial features. This includes international
printing, performance, OJI support etc.. I would expect it from netscape, 
after all they are a company with it's own agenda, but not from a community
based project like mozilla.org

Comment 15

[Erik van der Poel]

Netscape has decided not to include bidi in Netscape 6. That means both on
screen and on the printer, and for all platforms (for Netscape 6, that means
Windows, Mac and Linux).

IBM is working on bidi, and mozilla.org is working with them to get those
changes into Mozilla. Some progress has been made, but it is hard to predict
when the code will be checked in, and it will probably be in ifdefs initially.
We don't know when the ifdefs will be turned on by default in Mozilla, and
Netscape doesn't know when bidi will be shipped as part of a Netscape release.

Moshev, are you a programmer? Perhaps you would like to help if you are so
anxious to see bidi printing support on Unix?

Comment 16

[Mike Kaply [:mkaply]]

Going back to the original text...

If the latin-1 tag in the ps file is changed, does the file print correctly?

Does the problem happen for other things besides Hebrew?

If Russian doesn't print correctly, I think you would have a much better 
argument of getting International printing fixed in general.

Comment 17

[Roland Mainz]

Stupid question: AFAIK is international printing supported/covered via
libXp/Xprt (the X print system)... Where's your problem ?

Comment 18

[moshev]

I'll bite :). Since i am a russian speaking too, i tested
www.rambler.ru - print to file - crash...
ok, let's try something else:
http://top100.rambler.ru/top100/Music/index.shtml.ru - print to file - crash..
finally - http://kulichki.rambler.ru - print to file - a file is created..
Now more ./mozilla.ps | grep iso - > 
	/Encoding isolatin1encoding def
Wow, i guess russian is not working too.
I don't know about Xprt (will check what it is on google in a moment), 
but does the user really wants to do anything else but press print to print?
I am attaching the mozilla.ps file from http://kulichki.rambler.ru 
for Postscript gurus to look at.

Now about myself, yes i am a programmer, but i've not done c/c++ for couple
of years (doing mostly java lately), and never programmed c/c++ on linux
other than simplest things, don't know enough of postscript to be of any help
and would not be able to dive into it without sacrificing my daily job+msc in cs
that i am doing right now. So may be i don't have the right to complain, but 
i thought that having a user input as detailed as i provide will help
in at least setting the priorities. I guess i'm wrong.

Comment 19

[moshev]

Attachment: print to file of russian site kulichki.rambler.ru

Comment 20

[moshev]

One other comment about bidi - i didn't ask for a bidi printing. most hebrew
pages are visual anyway, and i can read backwards, I just ask you to understand
that A with an umlaut or whatever is not similar to hebrew Aleph or russian Ia.

Comment 21

[Roland Mainz]

X print system can be easily enabled in Mozilla, but I don't know if I'm allowed
to give the info here how to enable&&configure it in the Zilla... 
Q to Hidetoshi Tajima... am I allowed to post your small README here ?

Comment 22

[moshev]

Not wanting to spam this bug report anymore, but at least on my system
the ghostview dies trying to show the mozilla.ps file in last (third)
attachement:

Error: /syntaxerror in -file-
Operand stack:
   unicodeshow
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--  
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--  
--nostringval--   false   1   %stopped_push   1   3   %oparray_pop   1   3  
%oparray_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--  
2   %stopped_push   --nostringval--   --nostringval--
Dictionary stack:
   --dict:930/983(ro)(G)--   --dict:0/20(G)--   --dict:89/200(L)--
Current allocation mode is Aladdin Ghostscript 6.01: Unrecoverable error, exit
code 1
local

Hope this helps.

Comment 23

[moshev]

Roland, it's not about that specific readme. I can write a script
to edit the postscirpt file, or dig on google and find some solution, 
but most users can't. And NS6.0 is hopefully going to become a popular browser,
so my real concern is what OTHER people will do? When i show someone how
easy it is to setup linux these days, do I also have to show them
how to use/program in perl so they can print from Netscape?

Comment 24

[Roland Mainz]

NO no, completely wrong. Printing via libXp/Xprt is _very_ simple.
1. Start the X11 print server (like you start your Xfree86 server):
Example: % Xprt :4&
2. Set a secret option in Mozilla (can't tell you yet, otherwise Hidetoshi will
cut me in little peaces :-) and tell it where it can find the X print server
(Xprt).
That's all. I18n etc. should be completly covered and the default settings for
Xprt should generate the proper PostSostScript code :-)

Comment 25

[moshev]

Ok, this is a start of a solution but let's play a somewhat
willing_to_mess_up_with_config linux user that installed vanilla mandrake 7.1:
#man Xprt
No manual entry for Xprt
----
ok, let's try
#Xprt --help
----
looks much like starting an X server, good...

#Xprt

Fatal server error:
Server is already active for display 0
	If this server is no longer running, remove /tmp/.X0-lock
	and start again.

Aha, it needs to run on another display
#Xprt :1

Xp Extension: could not find config dir /usr/X11R6/lib/X11/C/print
--- 
Ha?
#Ctrl-Z, bg%1
#ps axw | grep Xprt
12222 pts/0    S      0:00 Xprt :1
Great, it seems it is running, 
now vi ./prefs.js
I think you get my point.

The real solution is to integrate whatever solution is there into
the standard build, provide the needed gui in mozilla prefs to configure
it properly if needed, help etc.., But! it is all post NS6.0 right?

I don't specifically care in this bug report about removing isolatin1encoding in
postscript files, if there is another solution, great. My point however remains
that it should not be post NS6.0 issue.

Thanks for bearing a flamewar in bugzilla, and sorry for it, 
Moshe Vainer
[e-mail] 
(if someone wishes to e-mail me about it off-bugzilla, feel welcomed)

Comment 26

[moshev]

Ok, i know everyone is tired of me but one last thing worth mentioning:
I fired up windows/ie5.0, went to http://www.rambler.ru and did a print to file.
(I have a ps printer). The output file although big (since it has all the fonts
encoded) is a valid postscript file, which when transferred to my Linux Box,
views great in gv with color, russian text and everything.
Why is it not possible to generate the same kind of output from mozilla?
If it is a valid .ps file, and is rendered perfectly with ghostscript, then
there should be no problem to print it on any PS printer.
And embedding fonts in ps output should not depend on true-type font support.
If mozilla can render the page, can't it embed the very same fonts
it uses for page rendering into the output ps?

Should i attach the resulting .ps file from ie that can be viewed with
ghostview? (it's large ~250k gzipped)

Comment 27

[Roland Mainz]

Yes, please attach it for comparisation. I'm currently building Mozilla with X
print enabled. But it will need at last ~45mins and I need some sleep now... see
you tomorrow...

Comment 28

[moshev]

Attachment: A gzipped postscript output from rambler.ru with ie 5 (~250k)

Comment 29

[moshev]

Anything new about this bug?
I have added the attachment as requested, I also see that lot of things
are being done for CJK for M18, but nothing for Hebrew.
How is Hebrew different from CJK regarding font substitution?

Comment 30

[Roland Mainz]

How to print from Mozilla with libXp/Xprt:
1. Edit $HOME/.mozilla/default/prefs.js and add:
-- snip --
user_pref("print.print_method", 1);
-- snip --

2. Start Xprt:
% Xprt -audit 4 :2&

3. Set X print display var and start Mozilla
% export XPDISPLAY=mysun:2
% ./mozilla
Type the printer name in the "print command" field.

(BTW: This assumes that Mozilla was compiled with --with-xprint)

It would be nice if someone from the Linux platform would attach the resulting
PS file here, AFAIK Xprt on Linux may be some bugs in the font handling...

Comment 31

[moshev]

This is extremely *user friendly*. I am not talking about this,
i am talking about a  solution for users, not for programmers. 
I personnaly can use sed and write scripts, i did not know that mozilla
is about educating people how to become computer wizards. 
May be i am wrong. I'll just stop bugging you all, since it seems that 
this project is not about producing multi-lingual, user-friendly, standard
compliant browser. I have said it before, and i will say it this one last time,
putting isolatin1 in a postscript file that does not originate from isolatin1
page is simply a bug, printing for international pages should either be
disabled, or fixed.

Comment 32

[Roland Mainz]

> This is extremely *user friendly*. I am not talking about this,
> i am talking about a  solution for users, not for programmers.

Brrr... stop. Please. Xprt should be set-up with the "normal" print system by an
administrator, not an user.
In Solaris >= 7/MU4 add the following line to /etc/init.d/lp:
-- snip --
   [ -f /usr/lib/lpsched ] && /usr/lib/lpsched
+  [ -x /usr/openwin/bin/Xprt ] && (/usr/openwin/bin/Xprt :1&)
-- snip --
Then restart the print system:
% /etc/init.d/lp stop
% /etc/init.d/lp start

Then Xprt runns forever - for all users - under localhost:1
Isn't THAT user-friendly ?

Comment 33

[moshev]

Sorry, please ignore my rant, now the real questions:
1. Are Linux distros supposed to set this up on installation,
2. if not should mozilla provide it on -install?
3. Should this pref be available via XUL?
4. if so, should i file separate bug on this?

5. I will certainly try it now on Linux and report the results.

Rgrds Moshe.

Comment 34

[Roland Mainz]

> Sorry, please ignore my rant, now the real questions:

No problem. I'll fight for libXp/Xprt... :-)

> 1. Are Linux distros supposed to set this up on installation,

Uhm... you can add Xprt to Linux print system startup, too. SuSE Linux comes
with Xprt.
Unformtunately you may run into the problem that Xfree86-Xprt doesn't contain
the fixes of Solaris8-Xprt (font glyphs wrongly placed etc.). Someone at Xfree86
mailinglist said that Sun engineering has comitted the patches back to X.org but
I cannot see them.
If any of the Sun engineers read this: Is it possible that I can get my clawn on
the source to build a Linux-x86 binary of Xprt-fixed ?

> 2. if not should mozilla provide it on -install?

????

> 3. Should this pref be available via XUL?

YES YES - file and RFE for this (like "Print dialog should support X11 print
system) and vote for it... :-)

> 4. if so, should i file separate bug on this?

see above

> 5. I will certainly try it now on Linux and report the results

Attach PostScript file, please !

Comment 35

[moshev]

I was just editing my other reply on this when you submitted your's, so i'll
just briefly repeat:
My attempt to start Xprt:

#Xprt -audit 4 :2 &
[1] 14116
Xp Extension: could not find config dir /etc/X11/xserver/C/print
# sort: -: write error: Broken pipe
Fatal server error:
no screens found
[1]+  Exit 1                  Xprt -audit 4 :2


All man Xprt, man -k Xprt, man XF86Config etc produced nothing usable.
This was done with MandrakeCooker XFree86 4.0.1 rpms.

So the current state of Linux (from my point of view, correct me if i'm wrong)
is that it does not support Xprt by default.

2. I will file a separate RFE for the prefs. (later today)
3. How come that my Lyx happily prints hebrew without the need for anything
else?
4. Would it help if i produce corresponding .lyx,.tex,.dvi,.ps for someone to
analyze?
5. <rantagain> Why oh why is it marked future? </rantagain>

Comment 36

[moshev]

Attachment: Attachment with original .lyx, and produced .tex,.dvi and .ps files from lyx 1.1.5 with hebrew support

Comment 37

[Roland Mainz]

> I was just editing my other reply on this when you submitted your's, so i'll
> just briefly repeat:
> My attempt to start Xprt:

> #Xprt -audit 4 :2 &
> [1] 14116
> Xp Extension: could not find config dir /etc/X11/xserver/C/print

Ahhhglllrr. I'll create an attachment for this.

> # sort: -: write error: Broken pipe
> Fatal server error:
> no screens found

"No screens found" normally means that Xprt can't find/setup a printer.

> [1]+  Exit 1                  Xprt -audit 4 :2

> All man Xprt, man -k Xprt, man XF86Config etc produced nothing usable.
> This was done with MandrakeCooker XFree86 4.0.1 rpms.

See attachment.

> So the current state of Linux (from my point of view, correct me if i'm wrong)
> is that it does not support Xprt by default.

I'll fix that...

> 2. I will file a separate RFE for the prefs. (later today)

Please add bug reference.

> 3. How come that my Lyx happily prints hebrew without the need for anything
else?

Unknown.

> 4. Would it help if i produce corresponding .lyx,.tex,.dvi,.ps for someone to
analyze?
> 5. <rantagain> Why oh why is it marked future? </rantagain>

Unknown. See BUG_ACTIVITY.

Comment 38

[Roland Mainz]

Attachment: Xprt(1) manual page from public Solaris 7 Xsun patch

Comment 39

[moshev]

Thanks for the man page, however:
1. it does not help me in setting up the config file for Xprt (XpConfig &
Xprinters) since there is no syntax description for these files
2. You are trying to help me specifically with hebrew printing, for which i am
very thankfull, but this is not what my problem is, my problem is that mozilla
as a desktop (not server) product is only suitable for english users, or very
computer savvy users, and it is my belief that -
I. it is contrary to the goals of this project
II. other programs are doing it without the need to be computer savvy
III. All other programs that are doing it rely on embedding existing fonts in
the output ps file, and i see no reason why mozilla should not do the same
IV. even without the support of Xprint, or without the needed fonts being on the
system, putting the string "isolatin1" into an output postscript file for a page
that is absolutely not "isolatin1" is simply a bug, and should be fixed
regardless of other developments on this issue. It is basically the same as
hardcoding a font name for HTML page, let's say "microsoft sans serif" without
giving the opportunity to change it for e.g. "helvetica" , and then dumping core
if font is not found - a simple case of a bug.

Comment 40

[Roland Mainz]

Attachment: X11 xprint config files for Xprt missing in some Linux distributions (mime encoded, part 1)

Comment 41

[Roland Mainz]

Attachment: X11 xprint config files for Xprt missing in some Linux distributions (mime encoded, part 2)

Comment 42

[Roland Mainz]

Attachment: X11 xprint config files for Xprt missing in some Linux distributions (mime encoded, part 3)

Comment 43

[Roland Mainz]

Attachment: X11 xprint config files for Xprt missing in some Linux distributions (mime encoded, part 4)

Comment 44

[Roland Mainz]

Attachment: X11 xprint config files for Xprt missing in some Linux distributions (mime encoded, part 5)

Comment 45

[Roland Mainz]

Created tons of attachments (seems that BugZilla has problems with larger
attachments... ;-( ).
Use "munpack" to create original file (X11_etc_xpconfig.tar.gz):
-- snip --
% munpack *
Saving part 1 of 5 [e-mail]
Saving part 2 of 5 [e-mail]
Saving part 3 of 5 [e-mail]
Saving part 4 of 5 [e-mail]
Saving part 5 of 5 [e-mail]
X11_etc_xpconfig.tar.gz (application/octet-stream)
-- snip --

Comment 46

[moshev]

Roland Thank you very much. I have also just now seen your posts on
http://www.xfree86.org/pipermail/xpert/2000-August/000907.html
and yes, one of the problems is probably the lack of documentation. 
If docs are available, i guess then it's the distro's job to integrate the
configs in the install problem. I'll try with your attachment later today and
report back on any success or otherwise.

Comment 47

[Roland Mainz]

> Thanks for the man page, however:
> 1. it does not help me in setting up the config file for Xprt (XpConfig &
> Xprinters) since there is no syntax description for these files

Sorry, I needed some food (otherwise my brain will activate sleep mode :) and
some time to figure out that BugZilla produces nasty errors when attempting to
create large attachments.

> 2. You are trying to help me specifically with hebrew printing, for which i am
> very thankfull, but this is not what my problem is, my problem is that mozilla
> as a desktop (not server) product is only suitable for english users, or very
> computer savvy users, and it is my belief that -

Other locales simple require more work on the administrator side.

> I. it is contrary to the goals of this project
> II. other programs are doing it without the need to be computer savvy
> III. All other programs that are doing it rely on embedding existing fonts in
> the output ps file, and i see no reason why mozilla should not do the same
> IV. even without the support of Xprint, or without the needed fonts being on >
> the
> system, putting the string "isolatin1" into an output postscript file for a
page
> that is absolutely not "isolatin1" is simply a bug, and should be fixed
> regardless of other developments on this issue. It is basically the same as
> hardcoding a font name for HTML page, let's say "microsoft sans serif" without
> giving the opportunity to change it for e.g. "helvetica" , and then dumping >
> core
> if font is not found - a simple case of a bug.

AFAIK Xprint handles fonts in multiple steps:
1. Check if printer has the font - if yes: Use it.
2. If one fails: Dump all fonts in PS file (AFAIK the reason why Xprt PS output
is huge when default config is used (which assumes printer is a dumb one and has
no fonts)) - please correct me anyone here if I'm wrong

Comment 48

[Roland Mainz]

Sorry for the off-topic SPAM: For those who don't own "mpack":
ftp://ftp.andrew.cmu.edu/pub/mpack/mpack-1.5-src.tar.Z

BTW: Is there a BugZilla bug that attachments ~~>512MB causes a perl-script
within BugZilla to fail ?

Comment 49

[moshev]

Roland thanks again, some problems:
1. I had to run xfs -port -1 in order to run Xprt, otherwise it would
complain:

	Could not init font path element unix/:-1, removing from list!
	Fatal server error:
	could not open default font 'fixed'

I could not find how to set font path, and whether it should be set to the fonts
you provided or to the same fonts i use in X font server.

2. I have tried to print (after changing prefs etc,) but my printer would still
print just empty rectangles instead of hebrew. I am not sure it even 
used Xprt. I will attach mozilla.ps for you to inspect.
Thnks again.

Comment 50

[moshev]

Attachment: Output of http://www.qsm.co.il/Hebrew/qashetab.htm print with Xprt apparently running.

Comment 51

[Roland Mainz]

From PS intro of last attachment:
-- snip --
%!PS-Adobe-3.0
%%BoundingBox: 36 36 595 805
%%Creator: Mozilla (NetScape) HTML->PS
%%DocumentData: Clean8Bit
%%DocumentPaperSizes: A4
%%Orientation: Portrait
%%Pages: 0
%%PageOrder: Ascend
%%Title: Test Title
%%EndComments
% MozillaCharsetName: iso-8859-1
-- snip --

This PS file comes from Mozilla and _not_ from Xprt ("Creator" line looks
different). Currently "Save as File" does not use Xprt. You've to print and grab
the file from the print queue (better: create a print queue which dumps all
files into a dir instead to the printer).

BAD: I have problems getting Xprt running on Linux, it can't find any printers
(lpstat missing !?!?) ?
Any ideas ?

Comment 52

[moshev]

Unfortunately printing directly to printer produces the same results. 
It leads me to believe that nightlies are not compiled with --with-xprint
Can anyone confirm or deny it?

Comment 53

[Roland Mainz]

I can't confirm this but I assume that "nighlies" are build with ./configure;
make; make_tarball". Xprint support isn't included per default - therefore
nighlies will miss this feature.

Comment 54

[moshev]

I will then have to wait untill this is done (I really can not build mozilla
while at work..., and at home i have (don't laugh, i don't bother to upgrade) a
133mhz Pentium w/o internet)
Is there a tracking bug for inclusion of --with-xprint into builds?
Should i file one?

Comment 55

[Roland Mainz]

> I will then have to wait untill this is done (I really can not build mozilla
> while at work..., 

What about "% nice -n 18 make" ?

> and at home i have (don't laugh, i don't bother to upgrade) a
> 133mhz Pentium w/o internet)

=:-)

> Is there a tracking bug for inclusion of --with-xprint into builds?
> Should i file one?

Yes, please.

Comment 56

[Roland Mainz]

Patch 108376-12 (Xsun&Xprt patch) for Solaris _2.7_ is out, including some nice
Xprt fixes.
See
http://sunsolve.sun.com/pub-cgi/retrieve.pl?patchid=108376&collection=fpatches
for the README and
http://sunsolve.sun.com/pub-cgi/patchDownload.pl?target=108376&method=H for the
patch itself.

Comment 57

[Tobias Burnus]

> > Is there a tracking bug for inclusion of --with-xprint into builds?
> > Should i file one?
> Yes, please.
Since I couldn't find one, I added one; bug #52076

|It is basically the same as hardcoding a font name for HTML page, let's say 
|"microsoft sans serif" without giving the opportunity to change it for e.g. 
|"helvetica" , and then dumping core if font is not found - a simple case of a 
|bug.
Well, where is the difference. If you look closely at the source for ps
printing, you will realize that it only uses Times Roman (not even Courier for
printing monospace).

I haven't looked at Xprt (I have the same problems with starting, and building
takes ages on my PII for building Mozilla), but I if I understand this
correctly, Xprt + Mozilla--with-xprint allow to print monospace and sans-serif
and unicode etc.? Then XPrint seems to be *the* solution of many of the pending
unix bugs (maked as OS=Linux).

Comment 58

[Tobias Burnus]

Ok, I'm almost asleep. The bug id is bug 49947 and alread there for some time
(see depend). And for those who miss the UI for enabling the XPrint feature, it
is bug #49946 (also a dependence).

Comment 59

[Roland Mainz]

Has someone an URL with Hebrew X11 fonts (DPI=90) ? I'd like to add a PostScript
dump of libXp/Xprt printing http://www.qsm.co.il/Hebrew/qashetab.htm with
matching fonts...

Comment 60

[Roland Mainz]

Ignore that last message... seems the hebrew fonts were available.

I've put some low-low-resolution (!!) examples (for SPARCprinter 2) from Xprint
(Mozilla post-M18+Solaris 7 Xprt) on the WWW:
http://puck.informatik.med.uni-giessen.de/people/gisburn/work/mozilla/xprint/

Comments ?

Comment 61

[bobj]

cc'd [e-mail]

Comment 62

[shrirang khanzode]

spam : changing qa to sujay (new qa contact for Printing)

Comment 63

[Roland Mainz]

I'd like to attach new screenshots from upgraded Xprint - does anyone have some 
nice example URLs with many text, no frames and not-so-many images for the
following locales (I don't have scableable fonts for the other locales):
-- snip --
iso_8859_2
iso_8859_4
iso_8859_5
ar
iso_8859_7
iso_8859_8
iso_8859_9
iso_8859_15
-- snip --

Thanks !

Comment 64

[Roland Mainz]

Attachment: GIF from PostScript output (1st page, 2x zoom) of http://www.qsm.co.il/Hebrew/qashetab.htm printed via fixed (see bug 72087) Xprint module + Xprt(Solaris7+108376-21)

Comment 65

[Frank Tang]

can someone summarize what is the current status. Does any patch get provided. 
[e-mail] know the moxilla/gfx/src/xprint code will . please let him 
know what we need from here. 

Comment 66

[Roland Mainz]

Frank Tang wrote:
> can someone summarize what is the current status.

See below...

> Does any patch get provided.

BTW: Xprint has it's own BugZilla component ("Printing: Xprint"). Most evil 
stuff has been fixed except the XUL unix print dialog - which is horrible 
insufficient for Xprint. All other stuff has bugs in BugZilla and I am working 
on this... see below...

> [e-mail] know the moxilla/gfx/src/xprint code will . please let
> him know what we need from here.

Xprint status:
- Print now prints most pages in european/english languages correctly. Others 
should work, too - but I cannot verify this yet because I am currently working 
on the fontmetrics stuff (see below)... This bug has some GIFs from PostScript 
files (created with _very_ old code... newer code is far better from both 
visual and PS code quality) attached which shows that Xprint module works... I 
am going to file new GIFs once the fontmetrics code works again... A list of 
example URLs would be nice...
- Printing BIDI pages works (except the fontmetrics issue described below).
- Xprint should be (depends on the time I a wasting in getting r=/sr=/checkin 
for my stuff) fully functional in 0.9.2 (incl. images/fontmetrics issues) - 
except the print dialog code. This is out of my scope. Need help.

Known issues: 
1. We need a better print dialog which reflects all Xprint-special features (for 
example: Xprint can provide a list of all available printers. Xprint can get/set 
special printer attributes like available 
color/plex/orientation/number_of_copies and so on... Xprint can make life of 
users/admins far more easy compared to what Mozilla's native PostScript module 
(and other Unix-printing solutions... ;-(( ) offer(s)... Print dialog should 
reflect this functionality)... I would prefer that we share the _same_ dialog 
for both "native PostScript" and "Xprint" modules on Unix to avoid that we have 
twice the work for one goal...
2. Xprint module does not print/scale images properly yet. I am working on 
that... should be fixed soon if nothing goes wrong. If something goes wrong I 
may been some help from image gurus (pavlov,syd,etc.)...
3. Starting with the checkin of the 2ndRevampOfXprint patch (bug 78548) the 
nsFontMetricsXP.cpp has problems to return (find !?) fonts for some 
locales/heights/encodings/some_weired_font_attributes. The Xlib-toolkit suffers 
from the same issue - the new code in nsFontMetricsXP.cpp is a 1:1 
copy+s/Xlib/Xp/ from nsFontMetricsXlib.cpp... I am investigating this 
currently... should be fixed soon after killing image handling bugs - if nothing 
goes wrong. If something goes wrong I may need the help from ftang...
ftang... could you please take a look at the Xlib-toolkit and check why it 
cannot render some fonts (mainly asian/hebrew/etc. fonts), please ? This may 
help me a lot in killing the same bug in Xprint module... thanks !
4. Other minor issues are described in the bugs for the "Printing: 
Xprint"-BugZilla-component...

Problems:
It would be very nice of I would have two or three people which could do _fast_ 
r=/sr= for my patches. It's driving me nuts (sometimes =:-) that most of the 
time I am _waiting_ for r=/sr=/checkin for my patches (I do not have CVS write 
access). I do not have the space to hold a 2nd code tree on my disks (see bug 
72087 for a nice comment about this... :-(((( )... bigger patches always block 
further developments on my side (yeah yeah... I know... I should "file smaller 
patches"... =:-) I'll try that... :-)... ;-((

Goals:
- Get a fully functional and easy-to-use and easy-to-configure printing solution 
for Mozilla on unix - incl. _full_ i18n support
- Make Mozilla the default print system for platforms where Xprint (libXp+Xprt) 
is available (Solaris >= 2.7 for example) and get _rid_ of that (stupid) PS 
module on those platforms. I think we do not need it anymore once Xprint is 
fully functional. Xprint module supersets the functionality of Mozilla's 
native PS module, will be smaller (module size is currently 1/2 of the size of 
PS module - and code will continue to shrink, memory footprint on client side is 
also far smaller), faster, print jobs will be smaller (currently printing large 
text files with Xprt's PS DDX results in ~2.45 times smaller PS jobs than those 
generated with Mozilla's "hand-written" native PostScript module // smaler print 
jobs == jobs will be processed+printed _faster_) and has fully functional i18n 
support for all pages which could be rendered with Mozilla per default (no 
special config needed - just start Xprt [1]... =:-)

Uhm... and questions ?

[1]=You may want to configure Xprt to tell it to use available printer buildin 
fonts to get better quality and smaller print job sizes - but this is _optional_ 
- and only needs to be "done" ___once___ at ___one___ central location - Xprt - 
which can be shared by many computers (Xprint is cross-platform and 
network-transparent) - which makes it an ideal solution for thin-clients (no 
spooler system on client-side needed... all config stuff and heavy calculations 
are "done" on the server-side)...

Comment 67

[Roland Mainz]

Attachment: http://people.netscape.com/ftang/demo/utf8form.html printed with Xprint module prototype (DIN A4, 300dpi, output for dumb LaserJetIII PS with no buildin CJK fonts)

Comment 68

[Roland Mainz]

I've attached a sample PostScript job from Xprint module (incl. patches from bug
77210). Looks good so far (well... I do not have all fonts... and most CJK fonts
are only available as 75dpi versions on my system. But printer-buildin fonts are
printed as buildin fonts - and remaining fonts are taked from X11 fonts
(fallback))...

Comment 69

[Roland Mainz]

Attachment: http://people.netscape.com/ftang/demo/utf8form.html printed with Xprint module prototype (DIN A4, 300dpi, output for dumb LaserJetIII PS with no buildin CJK fonts) (more fonts, fixed font centering)

Comment 70

[Roland Mainz]

Can anyone who is interested in the Xprint solution please vote
(http://bugzilla.mozilla.org/showvotes.cgi?voteon=49947) for bug 49947 ("Please
add --with-xprint to nightly builds") ? Thanks !

Comment 71

[Roland Mainz]

RFE/bug 49947 has been implemented, Xprint is now part of the default build.

Comment 72

[Roland Mainz]

Attachment: http://www.google.co.il/advanced_search?hl=iw printed with 2002-04-14-08-trunk Mozilla + Xprint module, 300 DPI, using downloaded hebrew fonts

Comment 73

[Roland Mainz]

Reporter:
Can you confirm that attachment 79796 [details] is correct (I can't read hebrew...) ?
And is the quality OK for you ?

If yes I can make a short description how to print hebrew... :)

Comment 74

[Roland Mainz]

Attachment: http://www.google.co.il/advanced_search?hl=iw printed with 2002-04-21-08-trunk Mozilla + Xprint module, 300 DPI / US-Letter, using downloaded hebrew fonts

Comment 75

[Roland Mainz]

Attachment: http://www.google.co.il/advanced_search?hl=iw printed with 2002-04-21-08-trunk Mozilla + Xprint module, 300 DPI / DIN-A4, using downloaded hebrew fonts

Comment 76

[Simon Montagu :smontagu]

The Hebrew in the last three attachments looks correct to me, except for the
page title in the header. That is a separate issue, and I have filed bug 139297
for it.

Comment 77

[Roland Mainz]

Quick guide how to print hebrew with Mozilla using Xprint is available under
http://puck.informatik.med.uni-giessen.de/people/gisburn/work/xprint/quickguide_hebrew_iso_8859_8.txt
; Xprint FAQ is available under
http://puck.informatik.med.uni-giessen.de/people/gisburn/work/xprint/Xprint_FAQ.txt
and the current Xprt Linux x86 binary release can be downloaded from
http://puck.informatik.med.uni-giessen.de/download/xprint_linux_x86_006.tar.gz
(sounds hard but isn't, should take less than 10mins to get it working... :)

Comment 78

[Kenneth Herron]

Mass-resolving some bugs related to the old Linux/Unix printing code. The old code has been removed from the tree, and the bugs are all FIXED by the new cairo-based printing system.