Re: Added Pseudocolor Visuals for XFree86?
Ian Romanick wrote: Tim Roberts wrote: The problem is not XFree86, the problem is technology. I'm not aware of ANY commodity graphics chips that support a 12-bit palettized video display mode. That's mostly because Windows doesn't handle it, and if Windows doesn't handle it, there is no business case for developing it in hardware. Assuming there was such a chip, there are no architectural barriers to supporting it in XFree86.. The fact that ExCeed 3D (which runs under Windows) can support it leads me to believe that hardware support has little to do with it. Remember that you can have a pseudocolor visual on a display that is physically truecolor. It just means that the X-server has to remap everything. I suspect the real reason is that nobody has ever wanted this support bad enough to write a patch. :) Solaris/Xsun and the X11R6.8.0 tree both have Pseudocolor emulation modes (Xsun actually supports emulated StaticGray/Grayscale/StaticColor/etc., too) ... Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Printer-builtin fontpaths broken / was: Re: CVS Update: xc (branch: trunk)
David Dawes wrote:
On Thu, Feb 19, 2004 at 11:20:50PM +0100, Roland Mainz wrote:
David Dawes wrote:
David Dawes wrote:
CVSROOT:/home/x-cvs
Module name:xc
Changes by: [EMAIL PROTECTED] 04/02/11 13:11:26
Log message:
799. Some more font path checks.
Modified files:
xc/lib/font/fontfile/:
dirfile.c encparse.c fontfile.c
xc/programs/Xserver/hw/xfree86/:
CHANGELOG
Revision ChangesPath
3.18 +17 -1 xc/lib/font/fontfile/dirfile.c
1.20 +7 -2 xc/lib/font/fontfile/encparse.c
3.22 +30 -11xc/lib/font/fontfile/fontfile.c
3.3139+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG
David:
Somehow these changes broke Xprt's handing of printer builtin fonts
(e.g. font paths prefixed with PRINTER: which are enabled
dynamically on per-model-config basis).
Can you isolate which of the changes causes the problem by adding them
in one at a time?
Yes, it seems that my original observation was wrong. Not the
printer-builtin fonts are affected but parts of the font path are
dropped.
The following statement in xc/lib/font/fontfile/dirfile.c causes the
failure:
(from
http://xprint.freedesktop.org/cgi-bin/bugzilla/attachment.cgi?id=95action=view)
-- snip --
+ }
+ if (!found_font) {
+ FontFileFreeDir (dir);
+ fclose(file);
+ return BadFontPath;
}
-- snip --
It seems that the change now makes it mandatory that the Xserver allows
to drop invalid font path elements... ;-/
I guess that's this change:
70. Changed behavior of fontfile: don't drop the entire directory if some
fonts cannot be rendered (Egbert Eich).
What exactly is it doing that breaks the printer fonts?
It seems that my original observation about missing printer buildin
fonts was wrong. The server refused to start and I thought that this was
caused by problems with the printer buildin fonts (note that I have
modified the font code in my own tree - if someone tries to start Xprt
with an invalid (or missing) configuration the server now refuses to
start (this is mainly to get rid of the myths about Xprint caused by
server misconfiguration)). After some more debugging I realised that the
dropping of font path elements isn't supported by my codebase (since I
am working on a X11R6.6-based tree which misses the code which can drop
parts of the font path without aborting the server startup) so the
server fails to start. My fault... ;-(
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, CJAVASunUnix programmer
/O /==\ O\ TEL +49 2426 901568 FAX +49 2426 901569
(;O/ \/ \O;)
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Printer-builtin fontpaths broken / was: Re: CVS Update: xc (branch: trunk)
David Dawes wrote:
David Dawes wrote:
CVSROOT:/home/x-cvs
Module name:xc
Changes by: [EMAIL PROTECTED] 04/02/11 13:11:26
Log message:
799. Some more font path checks.
Modified files:
xc/lib/font/fontfile/:
dirfile.c encparse.c fontfile.c
xc/programs/Xserver/hw/xfree86/:
CHANGELOG
Revision ChangesPath
3.18 +17 -1 xc/lib/font/fontfile/dirfile.c
1.20 +7 -2 xc/lib/font/fontfile/encparse.c
3.22 +30 -11xc/lib/font/fontfile/fontfile.c
3.3139+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG
David:
Somehow these changes broke Xprt's handing of printer builtin fonts
(e.g. font paths prefixed with PRINTER: which are enabled
dynamically on per-model-config basis).
Can you isolate which of the changes causes the problem by adding them
in one at a time?
Yes, it seems that my original observation was wrong. Not the
printer-builtin fonts are affected but parts of the font path are
dropped.
The following statement in xc/lib/font/fontfile/dirfile.c causes the
failure:
(from
http://xprint.freedesktop.org/cgi-bin/bugzilla/attachment.cgi?id=95action=view)
-- snip --
+ }
+ if (!found_font) {
+ FontFileFreeDir (dir);
+ fclose(file);
+ return BadFontPath;
}
-- snip --
It seems that the change now makes it mandatory that the Xserver allows
to drop invalid font path elements... ;-/
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, CJAVASunUnix programmer
/O /==\ O\ TEL +49 2426 901568 FAX +49 2426 901569
(;O/ \/ \O;)
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Printer-builtin fontpaths broken / was: Re: CVS Update: xc (branch: trunk)
David Dawes wrote: CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/02/11 13:11:26 Log message: 799. Some more font path checks. Modified files: xc/lib/font/fontfile/: dirfile.c encparse.c fontfile.c xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.18 +17 -1 xc/lib/font/fontfile/dirfile.c 1.20 +7 -2 xc/lib/font/fontfile/encparse.c 3.22 +30 -11xc/lib/font/fontfile/fontfile.c 3.3139+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG David: Somehow these changes broke Xprt's handing of printer builtin fonts (e.g. font paths prefixed with PRINTER: which are enabled dynamically on per-model-config basis). Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 2426 901568 FAX +49 2426 901569 (;O/ \/ \O;) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: grep on Solaris
[EMAIL PROTECTED] wrote: Building 4.4.0 RC2 on Solaris gives the following on Solaris for xc/programs/Xserver/hw/xfree86 rm -f build.new echo #define BUILD_DATE `date +%Y%m%d` build.new echo #define CLOG_DATE `if tail CHANGELOG | grep -F -q '$XFree86:'; then tail CHANGELOG | grep -F '$XFree86:' | sed s,'.* \([0-9][0-9]*\)/\([0-9][0-9] *\)/\( [0-9][0-9]*\).*,\1\2\3,'; else echo 0; fi` build.new grep: illegal option -- F grep: illegal option -- q Usage: grep -hblcnsviw pattern file . . . + rm -f xf86Build.h + mv -f build.new xf86Build.h rm -f build.new /usr/xpg4/bin/grep needs to be used instead of the default /usr/bin/grep. BTW: It may be a good idea (for portabilty) to add /usr/xpg4/bin in front of $PATH when building on Solaris to be portable to other POSIX/Unix98-conformant platforms... Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 2426 901568 FAX +49 2426 901569 (;O/ \/ \O;) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Mozilla assumes unassigned chars in iso10646-1 FreeType fonts as assigned with XF4.4.0 trunk
Hi! Is anyone else seeing the problem that Mozilla now renders glyphs in iso10646-1 fonts which are not assigned (normally Mozilla scans iso10646-1 encoded fonts for valid glyphs via looking at non-zero width metrics and puts those glyphs into it's internal CCMap), e.g. the glyph 0 is rendered. I am getting lots of these little square boxes when viewing http://www.google.co.il/search?as_q=mozillanum=100hl=iwie=UTF-8oe=UTF-8btnG=%D7%97%D7%99%D7%A4%D7%95%D7%A9+%D7%91%D7%92%D7%95%D7%92%D7%9Cas_epq=as_oq=as_eq=lr=as_ft=ias_filetype=as_qdr=allas_occt=anyas_dt=ias_sitesearch=? on SuSE 8.2 + XF4.0.0 todays CVS trunk (original Xfree86 shipped with SuSE 8.2 is OK). Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 2426 901568 FAX +49 2426 901569 (;O/ \/ \O;) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Mozilla assumes unassigned chars in iso10646-1 FreeType fonts as assigned with XF4.4.0 trunk
Roland Mainz wrote:
Is anyone else seeing the problem that Mozilla now renders glyphs in
iso10646-1 fonts which are not assigned (normally Mozilla scans
iso10646-1 encoded fonts for valid glyphs via looking at non-zero width
metrics and puts those glyphs into it's internal CCMap), e.g. the glyph
0 is rendered.
I am getting lots of these little square boxes when viewing
http://www.google.co.il/search?as_q=mozillanum=100hl=iwie=UTF-8oe=UTF-8btnG=%D7%97%D7%99%D7%A4%D7%95%D7%A9+%D7%91%D7%92%D7%95%D7%92%D7%9Cas_epq=as_oq=as_eq=lr=as_ft=ias_filetype=as_qdr=allas_occt=anyas_dt=ias_sitesearch=?
on SuSE 8.2 + XF4.0.0 todays CVS trunk (original Xfree86 shipped with
SuSE 8.2 is OK).
More details:
I added a small piece of debug code:
-- snip --
Index: ftenc.c
===
RCS file: /cvs/xc/lib/font/FreeType/ftenc.c,v
retrieving revision 1.25
diff -u -2 -0 -r1.25 ftenc.c
--- ftenc.c 20 Nov 2003 22:36:34 - 1.25
+++ ftenc.c 12 Dec 2003 12:40:15 -
@@ -216,24 +216,26 @@
if(tm-mapping) {
if(tm-named) {
name = FontEncName(code, tm-mapping);
if(!name)
return 0;
glyph_index = FT_Get_Name_Index(face, name);
return glyph_index;
} else {
index = FontEncRecode(code, tm-mapping) + tm-base;
FT_Set_Charmap(face, tm-cmap);
glyph_index = FT_Get_Char_Index(face, index);
return glyph_index;
}
} else {
if(code 0x100) {
index = code;
FT_Set_Charmap(face, tm-cmap);
glyph_index = FT_Get_Char_Index(face, index);
return glyph_index;
-} else
+} else {
+fprintf(stderr, # test 672.\n);
return 0;
+}
}
}
-- snip --
In the case of the iso10646-1 fonts the fprintf(stderr, ...) gets always
it... ;-(
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, CJAVASunUnix programmer
/O /==\ O\ TEL +49 2426 901568 FAX +49 2426 901569
(;O/ \/ \O;)
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Mozilla assumes unassigned chars in iso10646-1 FreeType fonts as assigned with XF4.4.0 trunk
Dr Andrew C Aitchison wrote: Is anyone else seeing the problem that Mozilla now renders glyphs in iso10646-1 fonts which are not assigned (normally Mozilla scans iso10646-1 encoded fonts for valid glyphs via looking at non-zero width metrics and puts those glyphs into it's internal CCMap), e.g. the glyph 0 is rendered. I am getting lots of these little square boxes when viewing http://www.google.co.il/search?as_q=mozillanum=100hl=iwie=UTF-8oe=UTF-8btnG=%D7%97%D7%99%D7%A4%D7%95%D7%A9+%D7%91%D7%92%D7%95%D7%92%D7%9Cas_epq=as_oq=as_eq=lr=as_ft=ias_filetype=as_qdr=allas_occt=anyas_dt=ias_sitesearch=? on SuSE 8.2 + XF4.0.0 todays CVS trunk (original Xfree86 shipped with SuSE 8.2 is OK). I'm not seeing little square boxes, and the page looks ok to my uninitiated eye. I've seen fonts which have little square boxes rather than gylphs with zero-width metrics. If you have one of these, the algorithm you describe wont help :-( It seems the font isn't broken - pfaedit doesn't show the squares - and Xfree86 on SuSE8.2 don't show this problem either. I filed a bug report under http://bugs.xfree86.org/show_bug.cgi?id=975 (Mozilla assumes unassigned chars in iso10646-1 FreeType fonts as assigned with XF4.4.0 trunk), including a test case and a screen dump from Xvfb ... likely a regression since older versions of Xfree86 did not show this behaviour (and I guess this is issue is very serious since it will render all UTF-8 encoded web pages unreadable in the case that mozilla finds fonts with many unassigned glyphs before other iso10646-1 fonts). Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 2426 901568 FAX +49 2426 901569 (;O/ \/ \O;) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Fwd: [Bug 931] New: RFE: Update xc/extras/freetype2/ to Freetype 2.1.7...]
David Dawes wrote: Do you mean xc/lib/font/Type1/ vs xc/lib/font/FreeType/ ? In my opinion the xc/lib/font/Type1/ should be retired since it causes server crashes such as Fatal server error: Beziers this big not yet supported and seems to have huge problems with rasterisation at higher resolutions. At Yeah, FatalError() from a font backend is bad. It ought to print a warning and return a relevant error code rather than killing the whole server. Unfortunately it isn't easy to handle that kind of error in a simple way... you can use setjmp/longjmp() for that case but that doesn't do any cleanup nor will it reset the Type1 engine... Yeah, it wouldn't be simple. Disabling the Type1 engine completely when one of these errors happens would even be preferable to aborting the whole X server. What about removing the CID support from the default setup ? [snip] What about handling *.pfa/*.pfb via the FreeType backend and let CID fonts be handled via the old Type1 backend ? That is the current default behaviour. Thanks for the hint (which helped narrowing down the issue... I thought I removed all CID fonts from my Linux machine but somehow I found another bunch... after removing the fonts the Xfree86 server is rock-solid again... :) Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 2426 901568 FAX +49 2426 901569 (;O/ \/ \O;) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[Fwd: [Bug 931] New: RFE: Update xc/extras/freetype2/ to Freetype 2.1.7...]
Hi! What about updating the FreeType code shipped with Xfree86 to version 2.1.7 before Xfree4.4.0 gets released (see bugzilla RFE below) ? Original Message Subject: [Bug 931] New: RFE: Update xc/extras/freetype2/ to Freetype 2.1.7... Date: Mon, 01 Dec 2003 23:51:57 -0500 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=931 Summary: RFE: Update xc/extras/freetype2/ to Freetype 2.1.7... Product: Client Libraries Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Freetype AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] RFE: Update xc/extras/freetype2/ to Freetype 2.1.7 (current version seems to be V2.1.4). -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Fwd: [Bug 931] New: RFE: Update xc/extras/freetype2/ to Freetype 2.1.7...]
David Dawes wrote: How does 2.1.4's handling of Type1 fonts compare with the Type1 backend? Do you mean xc/lib/font/Type1/ vs xc/lib/font/FreeType/ ? In my opinion the xc/lib/font/Type1/ should be retired since it causes server crashes such as Fatal server error: Beziers this big not yet supported and seems to have huge problems with rasterisation at higher resolutions. At Yeah, FatalError() from a font backend is bad. It ought to print a warning and return a relevant error code rather than killing the whole server. Unfortunately it isn't easy to handle that kind of error in a simple way... you can use setjmp/longjmp() for that case but that doesn't do any cleanup nor will it reset the Type1 engine... least for PS Type1 fonts the current code in xc/lib/font/FreeType/ is mature[1] enougth to let it handle all PS Type1 fonts (*.pfa, *.pfb). Unfortunately there are still the CID fonts where the FreeType backend and the FreeType library do not offer support for... but the question is - do we still need CID fonts when we have TTF/OTF font support ? I recently tracked down a problem report related to CID fonts, so I guess someone is using them. What about handling *.pfa/*.pfb via the FreeType backend and let CID fonts be handled via the old Type1 backend ? At least the risk of hitting the Beziers this big not yet supportedco. minefield will be greatly lowered - and the workaround would be to remove the CID fonts from the font path (which doen't harm most users... removing all PS Type1 fonts from the font path will harm LOTS of users... ;-(). Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 2426 901568 FAX +49 2426 901569 (;O/ \/ \O;) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[Fwd: [Bug 887] Calling XInitThreads and linking with pthread library causes deadlock in Xprint]
Hi! Can anyone review the patch in bug 887 and commit it to the CVS if it is OK, please ? Original Message Subject: [Bug 887] Calling XInitThreads and linking with pthread library causes deadlock in Xprint Date: Wed, 19 Nov 2003 05:02:43 -0500 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=887 --- Additional Comments From [EMAIL PROTECTED] 2003-19-11 05:02 --- Created an attachment (id=817) -- (http://bugs.xfree86.org/attachment.cgi?id=817action=view) Proposed fix for 2003-11-10-trunk -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You reported the bug, or are watching the reporter. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[Fwd: [Bug 898] New: mkfontscale creates ISO8859-15 lines for Type1 fonts which do not have the Euro symbol]
Hi! Does anyone have any clue what may cause the problem listed below ? Original Message Subject: [Bug 898] New: mkfontscale creates ISO8859-15 lines for fonts which do not have the Euro symbol Date: Sat, 22 Nov 2003 00:53:21 -0500 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=898 Summary: mkfontscale creates ISO8859-15 lines for fonts which do not have the Euro symbol Product: Application Version: unspecified Platform: All OS/Version: All Status: NEW Severity: critical Priority: P2 Component: other AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] mkfontscale creates ISO8859-15 lines for fonts which do not have the Euro symbol. Steps to reproduce: 1. Make a new temp. dir: % mkdir test_dir ; cd test_dir 2. get Helvetica.pfa (I'll attach it to this bug in a few secs) % cp /shared/projects/xf86_trunk/fonts/Helvetica.pfa . 3. Run mkfontscale % mkfontscale 4. Show fonts.scale: % cat fonts.scale Result: -- snip -- 5 Helvetica.pfa -adobe-helvetica-medium-r-normal--0-0-0-0-p-0-adobe-standard Helvetica.pfa -adobe-helvetica-medium-r-normal--0-0-0-0-p-0-iso10646-1 Helvetica.pfa -adobe-helvetica-medium-r-normal--0-0-0-0-p-0-iso8859-15 Helvetica.pfa -adobe-helvetica-medium-r-normal--0-0-0-0-p-0-iso8859-1 Helvetica.pfa -adobe-helvetica-medium-r-normal--0-0-0-0-p-0-microsoft-cp1252 -- snip -- Expected result: Same as above, excluding the the ISO8859-15 line: -- snip -- 4 Helvetica.pfa -adobe-helvetica-medium-r-normal--0-0-0-0-p-0-adobe-standard Helvetica.pfa -adobe-helvetica-medium-r-normal--0-0-0-0-p-0-iso10646-1 Helvetica.pfa -adobe-helvetica-medium-r-normal--0-0-0-0-p-0-iso8859-1 Helvetica.pfa -adobe-helvetica-medium-r-normal--0-0-0-0-p-0-microsoft-cp1252 -- snip -- Note that many other PS Type1 fonts have the same problem... ;-(( -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: twm makes uninitialized memory access after malloc()
Peter \Firefly\ Lund wrote: We have a report in Bugzilla (#464), concerning twm. This test can only be made on NetBSD: Couldn't it be tracked down with valgrind? In theory - yes. Or use Rational Purify or Sun Workshop/Forte dbx (which has similar functionality when you use the check -access command (more details on demand)). Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ [EMAIL PROTECTED] /O /==\ O\ MPEG specialist, CJAVASunUnix programmer (;O/ \/ \O;) TEL +49 641 99-41370 FAX +49 641 99-41359 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Patches for making X11 client+server buffer sizes tuneable
Hi! I filed two bugs+patches to allow users to change the buffer sizes on both X11 client + server on demand, see... 1. Xserver: http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=460 - RFE: Buffer size for the BIGREQUESTS extension should be tuneable 2. libX11: http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=466 - RFE: Increase libX11 default buffer size (and provide a new env variable as tuneable Comments/reviews/checkin welcome... :) Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ [EMAIL PROTECTED] /O /==\ O\ MPEG specialist, CJAVASunUnix programmer (;O/ \/ \O;) TEL +49 641 99-41370 FAX +49 641 99-41359 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
Juliusz Chroboczek wrote: RM Weired. I don't see that problem when running mkfontscale RM (Solaris2.7/SPARC build with Sun Workshop/Forte 7) ... Try -e. That's what I did (% mkfontscale-e $PWD # in the encodings/ dir) ... Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ [EMAIL PROTECTED] /O /==\ O\ MPEG specialist, CJAVASunUnix programmer (;O/ \/ \O;) TEL +49 641 99-41370 FAX +49 641 99-41359 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
Dr Andrew C Aitchison wrote: With Roland's fix, mkfontscale generates encodings.dir files containing the string (null), ie with lines like: big5-0 (null)(null)large/big5.eten-0.enc big5.eten-0 (null)large/big5.eten-0.enc viscii1.1-1 (null)./viscii1.1-1.enc.gz adobe-symbol (null)./adobe-symbol.enc.gz Weired. I don't see that problem when running mkfontscale (Solaris2.7/SPARC build with Sun Workshop/Forte 7) ... Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ [EMAIL PROTECTED] /O /==\ O\ MPEG specialist, CJAVASunUnix programmer (;O/ \/ \O;) TEL +49 641 99-41370 FAX +49 641 99-41359 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
2003_06_30 mkfontscale creates encodings.dir in wrong order
Hi!
Xfree86 source tree, pulled at 2003-06-30 this morning. It seems that
mkfontscale is generating the encodings.dir files in the wrong order.
The fontenc code expects the name filename order but mkfontscale
uses now filename name (which means that most encodings are not
recognised anymore when fonts.scale should be build).
I've attached a patch to fix the issue...
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ [EMAIL PROTECTED]
/O /==\ O\ MPEG specialist, CJAVASunUnix programmer
(;O/ \/ \O;) TEL +49 641 99-41370 FAX +49 641 99-41359Index: mkfontscale.c
===
RCS file: /cvs/xc/programs/mkfontscale/mkfontscale.c,v
retrieving revision 1.7
diff -u -r1.7 mkfontscale.c
--- mkfontscale.c 2003/06/20 15:49:52 1.7
+++ mkfontscale.c 2003/06/30 23:03:37
@@ -1210,7 +1210,7 @@
free(fullname);
fullname = n;
}
-encodingsToDo = listConsF(encodingsToDo, %s %s, fullname, *name);
+encodingsToDo = listConsF(encodingsToDo, %s %s, *name, fullname);
if(encodingsToDo == NULL) {
fprintf(stderr, Couldn't allocate encodings\n);
closedir(dirp);
Increasing maximum request size...
Hi! Are there any known side-effects of increasing the default request buffer size over the current value of 1MB (except that more memory is being consumed :) , e.g. -- snip -- Index: xc/programs/Xserver/include/os.h === RCS file: /cvs/xc/programs/Xserver/include/os.h,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 os.h --- xc/programs/Xserver/include/os.h28 May 2002 01:47:52 - 1.1.1.1 +++ xc/programs/Xserver/include/os.h20 Jun 2003 22:31:09 - @@ -65,7 +65,7 @@ #define MAX_REQUEST_SIZE 65535 #endif #ifndef MAX_BIG_REQUEST_SIZE -#define MAX_BIG_REQUEST_SIZE 1048575 +#define MAX_BIG_REQUEST_SIZE 8388600 #endif typedef pointerFID; -- snip -- ? Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ [EMAIL PROTECTED] /O /==\ O\ MPEG specialist, CJAVASunUnix programmer (;O/ \/ \O;) TEL +49 641 99-41370 FAX +49 641 99-41359 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 1200dpi bitmap fonts in the tree
Juliusz Chroboczek wrote: Is it me, or are we really shipping 1200dpi bitmap fonts as part of XFree86? xc/programs/Xserver/XpConfig/C/print/models/SPSPARC2/fonts/Courier.pmf The *.pmf files are no real fonts, they contain only the metrics for printer builtin fonts (those are usually scaleable, however the metrics in the PMF files are usually calculated for the maximum DPI supported by the matching Xprint DDX (PS DDX in this case). Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ [EMAIL PROTECTED] /O /==\ O\ MPEG specialist, CJAVASunUnix programmer (;O/ \/ \O;) TEL +49 641 99-41370 FAX +49 641 99-41359 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
