From julien.lafon at gmail.com Fri Jan 6 19:28:21 2006 From: julien.lafon at gmail.com (Julien Lafon) Date: Fri Jan 6 14:27:36 2006 Subject: [Xprint] Re: Suggested Xprint DDX reorg In-Reply-To: <200601051652.28778.ajax@nwnk.net> References: <200601051652.28778.ajax@nwnk.net> Message-ID: On 1/5/06, Adam Jackson wrote: > We've got five DDXes that are complex enough to need or want auxiliary tools > or config bits. Right now we have: > > xorg/Xprint > xorg/XpConfig > xorg/hw/xfree86 > xorg/hw/xfree86/utils > xorg/hw/dmx > xorg/hw/dmx/config > xorg/hw/darwin > xorg/hw/darwin/utils > xorg/hw/xwin > xorg/hw/xwin/xlaunch > > For parallelism I'd rather see the Xprint DDX moved under hw and its config > bits under that: > > xorg/hw/Xprint > xorg/hw/Xprint/XpConfig > xorg/hw/xfree86 > xorg/hw/xfree86/utils > ... > > Does anyone have a compelling case against this? See below. > If not I'll probably shuffle > this around sometime this weekend. It does not sound not logical to me - Xprint DDX is no physical hardware so why should it be tagged as such? Julien -- Julien Lafon Senior Staff Engineer, Hitachi From dparsons at debian.org Sat Jan 7 10:02:30 2006 From: dparsons at debian.org (Drew Parsons) Date: Fri Jan 6 18:03:36 2006 Subject: [Xprint] Re: Suggested Xprint DDX reorg In-Reply-To: References: <200601051652.28778.ajax@nwnk.net> Message-ID: <1136588550.6078.8.camel@pug.anu.edu.au> On Fri, 2006-01-06 at 19:28 +0100, Julien Lafon wrote: > On 1/5/06, Adam Jackson wrote: > > > > For parallelism I'd rather see the Xprint DDX moved under hw and its config > > bits under that: > > > > Does anyone have a compelling case against this? > > If not I'll probably shuffle > > this around sometime this weekend. > > It does not sound not logical to me - Xprint DDX is no physical > hardware so why should it be tagged as such? > Maybe "hw" could be renamed to "ddx"? That'd parallelise against the existing dix directory. Drew (I don't have strong opinions either way, so long as I don't have to redo the Xprint patch I just submitted :) ) From Alan.Coopersmith at Sun.COM Fri Jan 6 16:00:02 2006 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Fri Jan 6 19:00:37 2006 Subject: [Xprint] Re: Suggested Xprint DDX reorg In-Reply-To: References: <200601051652.28778.ajax@nwnk.net> Message-ID: <43BF0482.7010207@sun.com> Julien Lafon wrote: > It does not sound not logical to me - Xprint DDX is no physical > hardware so why should it be tagged as such? Neither is Xdmx, Xvfb, or Xnest. "hw" is a historical misnomer. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From felix.schulte at gmail.com Mon Jan 9 11:30:39 2006 From: felix.schulte at gmail.com (Felix Schulte) Date: Mon Jan 9 05:34:39 2006 Subject: [Xprint] Re: Suggested Xprint DDX reorg In-Reply-To: <17346.13599.408018.543110@hermes.suse.de> References: <200601051652.28778.ajax@nwnk.net> <17346.13599.408018.543110@hermes.suse.de> Message-ID: <74f15d5f0601090230lc2fa11lefebe92b7452a31d@mail.gmail.com> On 1/9/06, Egbert Eich wrote: > Julien Lafon writes: > > On 1/5/06, Adam Jackson wrote: > > > We've got five DDXes that are complex enough to need or want auxiliary tools > > > or config bits. Right now we have: > > > > > > xorg/Xprint > > > xorg/XpConfig > > > xorg/hw/xfree86 > > > xorg/hw/xfree86/utils > > > xorg/hw/dmx > > > xorg/hw/dmx/config > > > xorg/hw/darwin > > > xorg/hw/darwin/utils > > > xorg/hw/xwin > > > xorg/hw/xwin/xlaunch > > > > > > For parallelism I'd rather see the Xprint DDX moved under hw and its config > > > bits under that: > > > > > > xorg/hw/Xprint > > > xorg/hw/Xprint/XpConfig > > > xorg/hw/xfree86 > > > xorg/hw/xfree86/utils > > > ... > > > > > > Does anyone have a compelling case against this? > > > > See below. > > > > > If not I'll probably shuffle > > > this around sometime this weekend. > > > > It does not sound not logical to me - Xprint DDX is no physical > > hardware so why should it be tagged as such? > > Neither is vfb or nest. > 'hw' is really the wrong name here. It's historical. > Better would be 'ddx'. I do not want the Xprint files moved except hw/ gets renamed to ddx/ first (I wish this hw/ --> ddx/ rename would have been done during monolithic-->modular transition as the issue seems to be known since some time... :-(). -- _ Felix Schulte _|_|_ mailto:felix.schulte@gmail.com (0 0) ooO--(_)--Ooo From ajax at nwnk.net Mon Jan 9 10:33:36 2006 From: ajax at nwnk.net (Adam Jackson) Date: Mon Jan 9 10:34:47 2006 Subject: [Xprint] Re: Suggested Xprint DDX reorg In-Reply-To: <74f15d5f0601090230lc2fa11lefebe92b7452a31d@mail.gmail.com> References: <200601051652.28778.ajax@nwnk.net> <17346.13599.408018.543110@hermes.suse.de> <74f15d5f0601090230lc2fa11lefebe92b7452a31d@mail.gmail.com> Message-ID: <200601091033.39842.ajax@nwnk.net> On Monday 09 January 2006 05:30, Felix Schulte wrote: > On 1/9/06, Egbert Eich wrote: > > Julien Lafon writes: > > > It does not sound not logical to me - Xprint DDX is no physical > > > hardware so why should it be tagged as such? > > > > Neither is vfb or nest. > > 'hw' is really the wrong name here. It's historical. > > Better would be 'ddx'. Alternatively: Yes, it is, Xprint talks to printer hardware. > I do not want the Xprint files moved except hw/ gets renamed to ddx/ > first (I wish this hw/ --> ddx/ rename would have been done during > monolithic-->modular transition as the issue seems to be known since > some time... :-(). DDX is a misnomer too really, most of the DDXes have OS-interface bits that aren't device-dependent but rather platform-dependent, and core logic glue that's more or less common to all the DDXes. But this is missing the point. Regardless of what the directory is named, we're building N-1 servers under hw/ and 1 server under Xprint. The hw/ directory contains all of the code that is specific to given classes of output devices, _except_ the Xprint code. In other words, moving Xprint to hw/Xprint fixes layout; moving hw/ to ddx/ substitutes one bad name for another. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mozdev.org/pipermail/xprint/attachments/20060109/cac4e24a/attachment.bin From dparsons at debian.org Fri Jan 13 01:02:49 2006 From: dparsons at debian.org (Drew Parsons) Date: Thu Jan 12 09:03:56 2006 Subject: [Xprint] Xprint's use of FreeType: external symlink difficulties Message-ID: <1137074569.6414.50.camel@pug.anu.edu.au> Now that the basic Xprt server is working, I'm focussing on adding FreeType support. I understand we need this to get proper "wysiwyg" printing from Firefox (otherwise the page comes out all in Courier font). There are a number of problems, related to symlinks made to external code, namely freetype2 and ttf2pt1, both found previously in xc/extra. Some of the symlinks are made to internal source, so it's not simply a matter of installing libfreetype2-dev and working with public interfaces. The references start in xorg/Xprint/ps/PsText.c::PsPolyText8(), where an "#ifdef XP_USE_FREETYPE" is located, calling PsOut_DownloadFreeType(). This is found in psout_ft.c and calls PsOut_DownloadFreeType3 or PsOut_DownloadFreeType1 depending on the value of downloadfonttype. These two alternate paths give us the two symlink problems. I'll go over the two cases separately. Three, actually, but the third is inside X.org (using a header in a lib). 1) extras/freetype2 and USE_FT_INTERNALS PsOut_DownloadFreeType3( ) is defined in psout_ftpstype3.c. It #defines USE_FT_INTERNALS and thereby #includes "t42types.h". This header file was previously found in xc/extras/freetype2/src/type42. I'm not sure how t42types.h, but it will be related to FT_Get_PS_Font_BBox(), also defined under #ifdef USE_FT_INTERNALS. FT_Get_PS_Font_BBox is used in PSType3_generateOutlineFont(), but under "if (! ti->ttheader)". It probably needs #ifdef USE_FT_INTERNALS around it too. psout_ftpstype3.c also includes freetype2/freetype/internal/t1types.h via the symbol #include FT_INTERNAL_TYPE1_TYPES_H. This is provided externally by libfreetype2-dev. However t1types.h #includes FT_SERVICE_POSTSCRIPT_CMAPS_H, defined in internal/ftserv.h as . Previously in xc/extras/freetype2 there was such an internal/services directory, but in my Debian installation of libfreetype2-dev it is missing. I don't know if this is a Debian or FreeType2 packaging bug or an error in Xprint/ps for wanting to use FT_INTERNAL. One solution is to undef USE_FT_INTERNALS, but this will lose the definition of the Font BoundingBox. I don't know what the consequences of that would be. 2) extras/ttf2pt1 PsOut_DownloadFreeType1 is defined in ps/psout_ftpstype1.c. It calls ft2pt1_main( ), defined in xc/extras/ttf2pt1/ttf2pt1.c (in place of ttf2pt1 normal main() ). extras/ttf2pt1 seems to have quite a large number of extra code on top of the upstream original, specific to X.org. Most of it is specific to Xprint (controlled by "#ifdef XP_PSTEXT"). A half dozen or more symlinks to supporting files in extras/ttf2pt1 are made in Xprint/ps to allow ttf2pt1.o to be built. What is the best way to deal with this? Create a ttf2pt1 subdirectory below xorg/Xprint/ps ? 3) modular lib/Xfont ps/PsFTFonts.c refers to FTFontPtr, defined in modular lib/XFont/src/FreeType/ftfuncs.h. The path can be made directly in the monolithic build but in a modular system the header is lost. How should this be resolved? Will we have to make the Xfont module to start providing ftfuncs.h? These are all the symlink or #include problems I've logged so far related to freetype support in Xprt. Thanks, Drew