Closed Bug 24824 Opened 25 years ago Closed 17 years ago

[ps] Hebrew text prints as gibberish

Categories

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

x86
Linux
defect

Tracking

()

RESOLVED FIXED
Future

People

(Reporter: moshev, Assigned: dcone)

References

()

Details

Attachments

(17 files, 1 obsolete file)

7.30 KB, text/postscript
Details
224.05 KB, text/plain
Details
8.00 KB, text/postscript
Details
207.60 KB, application/octet-stream
Details
13.47 KB, application/octet-stream
Details
2.21 KB, text/plain
Details
512.42 KB, text/plain
Details
512.34 KB, text/plain
Details
512.39 KB, text/plain
Details
512.45 KB, text/plain
Details
86.32 KB, text/plain
Details
79.26 KB, text/postscript
Details
56.29 KB, image/gif
Details
389.26 KB, application/postscript
Details
395.23 KB, application/postscript
Details
301.12 KB, application/postscript
Details
301.14 KB, application/postscript
Details
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
Status: NEW → ASSIGNED
Target Milestone: M16
Summary: Hebrew text prints as gibberish → [PRINTING]Hebrew text prints as gibberish
Summary: [PRINTING]Hebrew text prints as gibberish → Hebrew text prints as gibberish
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.
Assignee: dcone → ftang
Status: ASSIGNED → NEW
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?

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.

Attached file The output ps file
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.
Assignee: ftang → dcone
Status: NEW → ASSIGNED
Maybe Xprt (X print server) can help here. Comments ?
Target Milestone: M16 → M17
Target Milestone: M17 → M18
Why M18? Any explanation why international printing
is not important enough?


Target Milestone: M18 → M26
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?
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
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.
Target Milestone: M26 → Future
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?
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 dcone@netscape.com's review. It will be checked in once he gives
us the GO
and we can get check-in approval from CVS gatekeeper.
<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
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?
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.
Stupid question: AFAIK is international printing supported/covered via
libXp/Xprt (the X print system)... Where's your problem ?
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.
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.
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 ?
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.
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?
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 :-)
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
moshev@easybase.com 
(if someone wishes to e-mail me about it off-bugzilla, feel welcomed)
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)
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...
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?
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...
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.

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

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

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 25028.967033476@castor.informatik.med.uni-giessen.de
Saving part 2 of 5 25028.967033476@castor.informatik.med.uni-giessen.de
Saving part 3 of 5 25028.967033476@castor.informatik.med.uni-giessen.de
Saving part 4 of 5 25028.967033476@castor.informatik.med.uni-giessen.de
Saving part 5 of 5 25028.967033476@castor.informatik.med.uni-giessen.de
X11_etc_xpconfig.tar.gz (application/octet-stream)
-- snip --
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.
> 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
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 ?
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.
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 ?

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?
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.
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?
> 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.
Depends on: 49946
Depends on: 49947
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.
> > 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).
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).
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...
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 ?
cc'd mkaply@us.ibm.com
spam : changing qa to sujay (new qa contact for Printing)
QA Contact: shrir → sujay
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 !
can someone summarize what is the current status. Does any patch get provided. 
katakai@japan.sun.com know the moxilla/gfx/src/xprint code will . please let him 
know what we need from here. 
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...

> katakai@japan.sun.com 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)...
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))...
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 !
RFE/bug 49947 has been implemented, Xprint is now part of the default build.
Blocks: 115714
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... :)
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.
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... :)
Summary: Hebrew text prints as gibberish → [ps] Hebrew text prints as gibberish
Blocks: 214800
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.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: