Closed
Bug 144663
Opened 23 years ago
Closed 16 years ago
[meta bug] Linux/Unix TrueType printing
Categories
(Core :: Internationalization, enhancement)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: bstell, Assigned: bstell)
References
Details
(Keywords: intl, meta, topembed-)
This is a meta (or overview) bug to track the code changes necessary to add TrueType printing to the Linux/Unix client
Assignee | ||
Comment 1•23 years ago
|
||
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%
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 4•22 years ago
|
||
batch: adding topembed per Gecko2 document http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed
Assignee | ||
Comment 5•22 years ago
|
||
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
Updated•22 years ago
|
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
Assignee | ||
Comment 7•22 years ago
|
||
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.
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]
Assignee | ||
Comment 9•22 years ago
|
||
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 11•22 years ago
|
||
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.
Target Milestone: mozilla1.3alpha → ---
Comment 12•22 years ago
|
||
> 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•22 years ago
|
||
> 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•22 years ago
|
||
>> 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•22 years ago
|
||
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.
Assignee | ||
Comment 16•22 years ago
|
||
would people mind moving the discussion of server vs client printing to a different bug?
Updated•16 years ago
|
Comment 18•16 years ago
|
||
I think cairo handles this now.
Status: NEW → RESOLVED
Closed: 16 years ago
Component: MathML → Internationalization
QA Contact: mathml → i18n
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•