144663 - [meta bug] Linux/Unix TrueType printing

Status: RESOLVED WORKSFORME

(Core :: Internationalization, enhancement)

Description

[kill this account]

This is a meta (or overview) bug to track the code changes necessary to add 
TrueType printing to the Linux/Unix client

Comment 1

[kill this account]

From an email:
=============================================================================

                          TrueType Printing

                                                              v5
Phase 1: Get the current code in.

Phase 2: Add support for Type1/Type3.
         Add support for large character sets when using
             Type1/Type3.


=================================================================
Phase 1 Work
=================================================================

1 Build a Demo
-----------------------------------------------------------------
This is a "proof of concept".

1.1 Hack OpenOffice code to do incremental glyph loading     100%
1.2 Hack OpenOffice code to make Type11 font.                100%
1.3 Hack moz to call OpenOffice code to make Type11 font     100%
    core tables.
1.4 Hack moz to call OpenOffice code to incrementally        100%
    load glyphs.
1.5 Hack OpenOffice code to check if core font tables        100%
    already loaded.
1.6 Hack moz to get prefered font from user font pref.       100%
1.7 Hack moz to use TrueType metrics.                         85%
    Still need to fix nsFontMetricsPS::RealizeFont().
1.8 Hack Ghostscript to display incrementally loaded Type11  100%
    fonts. Got 3 of 4 fixes checked into Ghostscipt. Fix 
    for composite chars not approved.


2 Fix Ghostscript
-----------------------------------------------------------------
Make necessary fixes to Ghostscript.
This needs to be done a early as possible so the changes have
field testing and more systems have the fixed GS code.

2.1 Fix GS to read metrics from inc loaded glyph data.       100%
2.2 Fix GS to pass metrics from inc loaded glyphs.           100%
2.3 Fix GS to use lsb/aw from inc loaded glyphs.             100%
2.4 Fix GS to recognize negative lsb as negative.            100%
2.5 Fix GS to handle composite glyphs lsb.                   -NA-
    Problem was actually in the OpenOffice psprint code.


3 Make Font Catalog Shareable
-----------------------------------------------------------------
Currently font catalog code and memory is duplicated by X display
code and printing code. The font catalog should be a service. 
Call it: Font Catalog Service (FCS)

3.1 Spec IDL for font catalog service.                         0%
3.2 Separate font catalog code from X display code.           50%
3.3 Code FCS interface.                                        0%
3.4 Modify printing code to use FCS.                           0%
3.5 Modify X display code to use FCS.                          0%


4 Common Class Interface for TrueType and Postscript Fonts
-----------------------------------------------------------------
The current print code assumes the font is a Postscript font.
Need a common interface that hides detail of font type.

4.1 Define common base class for TrueType and Postscript       0%
4.2 Modify Postscript code to use common interface.            0%


5 Glyph Fill In and Font Fallback
-----------------------------------------------------------------
The printing code does not check if the font has a glyph for
a give character so it may print blanks/boxes.

5.1 Add code to support a list of fonts.                       0%
5.2 Add code to check if current font has glyph.               0%
5.2 Add code to find a fallback font if current font does      0%
    support the char.
5.3 Add code to select between Postscript and TrueType fonts   0%
5.4 Add list of fallback fonts.                                0%


6 Code Generic Mozilla TrueType Printing Code
-----------------------------------------------------------------
Write code to insert core font and to incrementally load the 
glyphs.

6.1 Check font catalog service (FCS) for CSS specified font.  75%
    Basic code written for demo.
6.2 If font in previous step not found check FCS for user     75%
    specified font pref. Basic code written for demo.
6.3 Code to get overall font metrics (RealizeFont)             0%
6.4 Code to load core tables.                                 75%
    Basic code written for demo.
6.5 Code to load incremental glyphs.                          75%
    Basic code written for demo.
6.6 Add pref to disable TrueType printing.                     0%


7 Code Type11 Specific Font Code
-----------------------------------------------------------------
This is the code that actually generates the core Type11 tables
and the incremental glyphs.

7.1 Decide if this code is part of moz or not.                 0%
    We could fix the OpenOffice code and use that.
    We could write our own code.
    We could fix FreeType2 and use that.
7.2 Code to generate the core Type11 tables.               50-75%
    Basic code written for demo.
7.3 Code to incrementally load Type11 glyphs.              50-75%
    Basic code written for demo.
7.4 Fix code that gets lsb.                                  100%
7.5 Write code to address gsave/grestore/showpage. The         0%
    The grestore operation "deletes" the glyphs that 
    have been incrementally loaded since the last gsave. 
    The showpage operation should be logically considered 
    to also do this since 3rd party code may do a gsave/
    grestore on the page boundaries as a side effect of 
    opertions such as 2-UP or double-sided printing.


8 Code to Detect Ghostscript Needs Update
-----------------------------------------------------------------
During installation moz needs to detect if Ghostscript needs 
upgrade and if so inform the user.

8.1 Code to detect Ghostscript (GS) supports Type11 with       0%
    incremental glyph loading.
8.2 Code to inform user that GS needs upgrade.                 0%

Comment 2

[Jay Yan]

Frank, I've talked with Pete, this work' target milestone is mozilla 1.3 alpha,
(in your email, this is 12/4/2002)
-Jay

Comment 3

[Jay Yan]

Frank, please see my last comment.

Comment 4

[Marek Z. Jeziorek]

batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html

Comment 5

[kill this account]

bug 144664 Font Catalog Service

bug 144665 common printing interface for Postscript and TrueType fonts

bug 144666 Glyph Fill In and Font Fallback

bug 144668 Code Mozilla TrueType Printing Code

bug 144669 Code subsetted Type42 Specific Font Code

Comment 6

[aruhi]

Nominating this bug as WONTFIX

why?

small reality-check:
* there is no module owner for the PS module, even if you do this work you will
not fix all the other bugs in one step (around 50 or more critical bugs). noone
has cared in the last two years to fix bugs except crashers and other minor
try-to-keep-it-alive surgery - and the results are not very good either. just
adding Truetype support does not help, you would have to fix all the others bugs
- too. who will do that ? who will maintain the module ? there were no
volunteers in the past and it does not look like that there are much volunteers
in the future
* we already have Truetype support with the XPrint module, this work is
duplicate effort - the engineering time should be focuses on other issues
instead of 
* people want the PS module DEAD since it completely rotten - please let it die
NOW and stop trying to keep it alive with infusions of your blood and rare time

Comment 7

[kill this account]

X font technology has been severely hampered over the last 17 years by the 
design decision to put the font handling on the X server side. New technology 
is delayed until the user upgrades the X server and this often is not done for
1-3 (or more) years. This problem of deployment delay is one of the main reasons 
Xft has font handling on the client side.

Xprint continues with this same X server side font handling design decision and 
hence will continue to be years late in bringing features to the end user.

You are free to put your effort into Xprint. I will be putting my effort into
something that will bring features to the user in a far more timely fashion.

Comment 8

[Art Vedas]

Brian Stell:
1) we appreciate your enthusiasm about getting this feature running - but the PS
module is dead. the package maintainers want it dead (except Redhat maybe)
there is no qualified default maintainer for this code in sight (most of the
issue reports written since the year 1999 were send to /dev/null), polls were
done, end-of-support announcements are out and there are bugs filed to disable
it by default in the mozilla tree - which means even IF you are finishing this
part some day in the future no enduser will notice it
you are at least nine months too late with this work

2) we doubt that this work has much value for the community - adding Truetype
printing using Type42 fonts will not work on printers which do not support PS
level 3 - which means you are adding a feature which renders more then 80% of
printers useless
enabling such a feature by default is a grantee that you make the module more
useless than it is today

3) implementing Type42 support is not even half the work to harness the PS
module for end-users again. the code is substantial horked, no real work since
2000 was spend on this code, it lacks many features which are mandatory for the
enterprise and for the plain enduser, the output quality just sucks, many
printers abort jobs due errors and no qualified default maintainer in sight

the list of problems is endless. noone is looking at the 42 issues filed - most
of them were not touched since YEARs!!

we are sorry for you, but 'Whatever it is, it's dead, Jim.' [from Star Trek, The
Original Series]

Comment 9

[kill this account]

The current plan it Type8 not Type11 (or Type42 which only support small 
character sets).

> there are bugs filed to disable it by default in the mozilla tree

What's the bug number?

Comment 10

[kill this account]

By the way, what's the alternate plan for printing?

Comment 11

[Pete Zha]

target mile stone has been defined in children bugs. So I just remove milestone
from the root one. First working version is hopeful to check in before 1.3b. It
include following bugs:(bug 144664, bug 144665, bug 144668, bug 144671, bug
180473). Please see the dependency tree for details.

Comment 12

[Jungshik Shin]

> 2) we doubt that this work has much value for the community - adding Truetype
> printing using Type42 fonts will not work on printers which do not support PS
> level 3 - which means you are adding a feature which renders more then 80% of
> printers useless

 Although Brian already wrote that he's not going to use CIDFont type2(or type 11)
which is different from type42 (type42 has been supported by PS 20xx), 
I don't think you made a good argument against using type11 (CIDFont type2).
You seem to assume that PS printers dominate the printer market (well
at higher end, that's certainly true) when you wrote that 80% of printers
would be made useless. In reality, most of printers sold to end-users
are non-PS printers. 
Let me ask you this. How many percentage of end-users do you think
own a  postscript printer? Many of them may have access to PS printers
at school, work and printer shops. However, the vast majority of them
don't have a PS printer at home. What they have instead is a much
cheaper PCL 4/5/6 printer. Therefore, they have to filter their printer
jobs through ghostscript no matter what font type is used in the PS output
of Mozilla. Therefore for them, it doesn't matter at all what type
of font is used provided that the font type is supported by relatively
new version of ghostscript deployed in the field. It's GNU ghostscript 7.x
these days and it's a pretty good PS level 3 interpreter. Thanks to
folks at http://www.linuxprinting.org and http://www.cups.org, 
it's getting easier and easier to configure printing subsytem in Linux
and Unix. As its name imples, CUPS(Common Unix Printing System) 
is not only used by Linux/FreeBSD but also began to be used under
commercial Unix.  

As for Xprint, I totally agree with Brian's assessment of it in relation
to server-side font vs client-side font. I'm well aware that Xprint
works _right now_ (even for complex scripts as long as 
they can be rendered on the screen by Xlib module.
I was pleased to be able to print out my Old Korean
sample page with Xprint) and 
Roland has been putting a lot of time into it.
It's very nice to have it. However, I wouldn't  say it's the 'future' of
printing under Unix/X11. Especially, I would never agree
to kill 'ps' module in favor of 'Xprint'. 

IMHO, the future of printing in Unix/X11 lies in
something like Xft (may I call it 'XftPS'?) which
is tightly glued with fontconfig in CSS2 font resolution.
Working together with fontconfig is important to 
get WYSWYG in Unix/X11. 
Xft widely used for rendering on the screen 
uses fontconfig to select fonts and map CSS2 font specification
to actual fonts. To match what's rendered on the screen
with what's printed on paper, printing library('XftPS') also
needs to use fontconfig. That way, we can achieve 
the same level of WYSWYG as found in MS Windows and MacOS. 

Brian,  you mentioned about the need to make use of
fontconfig last summer, but I couldn't find any reference
to it in most bugs tracked here. What's your plan of
'font selection/CSS2 font resolution' routine? Are you
gonna roll out your own or rely on fontconfig somehow? 

Comment 13

[Christopher Blizzard (:blizzard)]

> these days and it's a pretty good PS level 3 interpreter. Thanks to
> folks at http://www.linuxprinting.org and http://www.cups.org, 
> it's getting easier and easier to configure printing subsytem in Linux
> and Unix. As its name imples, CUPS(Common Unix Printing System) 
> is not only used by Linux/FreeBSD but also began to be used under
> commercial Unix.  

And OSX, I might point out.

> Brian,  you mentioned about the need to make use of
> fontconfig last summer, but I couldn't find any reference
> to it in most bugs tracked here. What's your plan of
> 'font selection/CSS2 font resolution' routine? Are you
> gonna roll out your own or rely on fontconfig somehow? 

fontconfig has got to be used for the matching otherwise you end up with
different fonts being used on screen and on paper, which is exactly what we are
trying to avoid.

Comment 14

[Jungshik Shin]

>> CUPS(Common Unix Printing System) 
>> is not only used by Linux/FreeBSD but also began to be used under commercial
Unix.  
> And OSX, I might point out.

  Mac OS X is a commercial Unix (by far the most widely used one), isn't it ? :-)


> fontconfig has got to be used for the matching otherwise you end up with
> different fonts being used on screen and on paper

 Absolutely.  I can't agree with you more. That's why I asked a question because 
I couldn't find any trace of it (I didn't look very hard, though)  in bugs
tracked here. 

Comment 15

[jch]

Xprint may seem like an easy fix for Unix's printing problems, but it's really
not a reasonable solution.

The X11 Window System has good support for window management and event
distribution, but suffers a severe case of brain-damage when it comes to
rendering.  Xprint applies X11's rendering model to printers; thus, it throws
out what is good about X11 and only keeps the bad.

You will realise that the version of Xprint that comes with XFree86 is not
usable; this is clear indication that nobody at XFree86 is actually interested
in Xprint.

Xprint may seem a neat way of solving Unix's printing problems, but it's really
only worthwile as a short term hack.  With Xprint, you will get hopelessly
stuck as soon as you try to implement something that Xprint doesn't directly
support -- like CSS2, for example.

Comment 16

[kill this account]

would people mind moving the discussion of server vs client printing to a
different bug?

Comment 17

[kill this account]

*** Bug 90385 has been marked as a duplicate of this bug. ***

Comment 18

[Karl Tomlinson (:karlt)]

I think cairo handles this now.