Re: A question about fonts
I don't think fontconfig will solve the problem on its own. I think the application will actually have to do the job of switching between fonts, but fontconfig can provide some information to help the application do a better job. fonctonfig provides the info for higher level libs (pango, harfbuzz) to do the switching. An app should never implement a switching logic directly (that confuses users when different app make different switching decisions instead of relying on system libraries) -- Nicolas Mailhot ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Custom font format
Le Lun 10 janvier 2011 12:59, Michael Thalmeier a écrit : Hi ! We are currently developing an application that is using xlib directly for all the drawing operations. Our problem is, that we have a huge library of fonts in a custom font format, that is currently not supported by the x server. Does anybody know what would be the best way to deal with such custom font formats ? Convert them to a standard OpenType format and access them through pango/cairo/harfbuzz+fontconfig+freetype. You don't want to bypass the normal font stack. It's hugely complex, and reimplementing part of it will cost you a lot more than converting fonts (or switching fonts). You also don't want to use the legacy core fonts backend (people who used to work on it dropped it as unmaintainable almose a decade ago). Save yourself pain, and just use normal codepaths others will maintain and enhance for you. -- Nicolas Mailhot ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: X11 fullscreen
Le Ven 29 janvier 2010 00:53, Russell Shaw a écrit : One can make their own widget libraries based on Xlib, then write apps using the libraries. Nothing hard about that (hard is relative;) On the text processing front, hard is not relative. Working solutions are quickly being reduced to pango or qt, with pango and qt sharing components (harfbuzz) because they can't really cope alone. Modern text processing is *very* hard. English speakers usually don't realize it till they're flooded with bug reports from non-English speakers (and, probably soon, reports by English speakers, as support for advanced latin typographic features is added to pango/qt). If you want any proof, just check the OpenOffice.org bug tracker. They've not replaced their legacy text stack with pango yet, and get new text bug reports almost every day. (Not that OO.o is especially worse than other apps of the same age, but it's a heavy-duty app so people do report bugs instead of cursing privately). -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Le Ven 29 janvier 2010 14:40, Russell Shaw a écrit : The right way is to make each font a smart font that is simply a C library plugin. In other words, you can't handle real-world fonts. Since those cost millions and can take months or even years to create (see stix), since people like to have many of them, and want to interoperate with other people that use fonts in existing formats on other systems, I can't see how your advice is anything other than utterly wrong and dangerous. Unless someone has a few billions to blow to check if your idea is workable. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Question about unicode ranges in X fonts (TrueType)
Hi, Please target fontconfig and pango (or the equivalent QT lib) for any software with i18n text/font needs. They've been written precisely for this and are standard on all *nix systems (and are starting to see win32 deployments). Fedora has already started for a few releases to reduce the XLFD perimeter : new fonts (typically, the complex Opentype fonts you want to query) are not declared as XLFD anymore, old traditional XLFD fonts are not installed by default (breaking all the apps that assumed they'd be available forever and did not test for them). By the time you've finished development, I'd expect enterprise distributions such as RHEL to follow suit. Regards, -- Nicolas Mailhot Fedora fonts SIG http://fonts.fedoraproject.org/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: May I rework XKB ?
Le Mar 17 novembre 2009 08:51, Dirk Wallenstein a écrit : -- By taking a common pc-105 keyboard and holding down the AltGr/ISO-Level3-Shift modifier , all the alphabetic keys can be equipped with functionality like cursor-cross, insert, delete, home, etc. With the help of XKB's Redirect-Key-Action it would even be possible to have word-wise cursor movement in all text edit fields. All without leaving the home row. Please do not try to implement such gross hacks. iso-Level3 is already taken for i18n support, any app that relies on what you propose won't work for non-US users (the same can be said of iso-level5) And some xkb maps use iso-Level3 iso-Level5 to give access to technical symbols on the numpad, even for english. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Q] TrueType fonts
Le Mar 3 novembre 2009 04:39, liujm a écrit : seems the fonts are mostly rendered at client side now. not in the xserver, you can use any widgets you like. xtt and xft seems are not used now. such as gtk-pango-freetype qt-freetype Do not forget fontconfig. Using freetype directly without passing through a shaper such as pango that queries fontconfig is not the way to support text properly nowadays (I said pango because I don't remember the name of the equivalent QT lib; and to add to your GTK and QT paths a very common one is cairo=pango=freetype+fontconfig) -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: combining diacritics
Le Jeu 22 octobre 2009 16:54, Bèrto ëd Sèra a écrit : Yet, no matter how hard I looked for it, I could not manage to find a way to assign a sequence of symbols (like an HTML o#828;#836;#820;) to a key in a symbol file. http://bugs.freedesktop.org/show_bug.cgi?id=22649 -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: same linux installation, different font rendering
Anyway, there are many reasons why text rendering and size can vary from computer to computer (installed fonts, text rasterizer options, user preferences, GPU+screen hardware capabilities, driver capabilities) and a good application layout needs to be able to adapt to them. If it can't that's an application bug. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XI2 = moving target?
Le lundi 27 juillet 2009 à 12:19 +1000, Timothy S. Nelson a écrit : On Sat, 25 Jul 2009, Jim Gettys wrote: For curiosity's sake, have people actually seen keyboards with more than 248 keys? - Jim No, but I had this idea, see, of having one keyboard for each hand, and merging their events together at the kernel level. A modern smart programmable remote should probably be considered a device with more than 248 keys, since I don't think it tells the system which keys have been programmed at a moment so you have to assume all the keys that can be programmed exist -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XI2 = moving target?
Le samedi 25 juillet 2009 à 13:31 -0400, Jim Gettys a écrit : That isn't a good reason: keycodes are arbitrary, a simple table lookup to remap them to 8-255 is an easy solution, much easier than the alternatives, unless I'm missing something... keycodes are not arbitrary, the codes 255 have a standardised meaning, if you remap them they don't behave like they should according to the symbol printed on them. Also it is very common to have multiple input devices nowadays that all have some keycodes 255 so any remapping solution would need to be able to manage parallel hotplug of devices with different requirements (in fact what is un-common is devices that only use keycodes 255, I tried to buy one last time I was in the local chinatown to avoid dealing with this issue — they don't exist anymore) -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Le Mar 7 avril 2009 22:41, Mark Wagner a écrit : Thanks. Is there any documentation on the best way to do various high-level tasks, such as drawing images? As already discussed, for higher-level tasks you'll be better of going through a higher-level library such as cairo. cairo is not listed proeminently as an X component, because it also works on non-X systems but it is a core library for anything doing GUI stuff under X nowadays (with the exception of QT apps, but QT has a wider scope than cairo) -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Le Mar 7 avril 2009 02:43, Mark Wagner a écrit : I'm busy updating the Linux branch of a cross-platform toolkit that was last updated in 1994. ... Is there a good online document on how to program for XWindows using Xlib? XWindows changed a lot since 1994. Legacy stuff is still available but not really supposed to be used anymore, and in particular (and of special interest to toolkit authors) nowadays to display text you should go through XFT and fontconfig and not use legacy Core X11 font methods. IMHO, if you intend to update your toolkit for another 15 years of use, your should first evaluate switching to a higher-level library such as cairo instead of continuing to use XLib directly. cairo (via pangocairo) will use the modern font stack, and is now a foundation library for gtk, firefox, (soon) OpenOffice.org, and many others. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Le Mar 7 avril 2009 11:03, Tuomo Valkonen a écrit : On 2009-04-07, Nicolas Mailhot nicolas.mail...@laposte.net wrote: XWindows changed a lot since 1994. Legacy stuff is still available but not really supposed to be used anymore, and in particular (and of special interest to toolkit authors) nowadays to display text you should go through XFT and fontconfig and not use legacy Core X11 font methods. And legacy=bad? X core fonts still beat the shit out of the blur-fascist Xft/fontconfig XML-vomit mess with authors/packagers that hate the beautiful Helvetica with a passion. A font in 1994 included a few hundreds of glyphs at most without any complex composing rules, and weighted a few kiB. A font in 200x can include thousands of glyphs with complex composing rules, in MiBs of data. And that's just the font-level, without system font substitution management. The core X11 font system just can not scale to modern requirements. And that's ignoring its propensity to crash apps at the slightest excuse. I'm sure there are people who liked the simplicity of CGA screens too. You know what? They were good for their time, but they're history now. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Le Mar 7 avril 2009 12:27, Tuomo Valkonen a écrit : The requirements haven't changed in twenty years. They have. Systems now have Unicode locale as default, and font foundries do not use the same formats as twenty years ago. What has no changed is that apps using core fonts just crash all the time. Blurring is the approach of the lazy arrogant elite that feeds shit to the masses, You're probably the only person on the list that can't figure how to disable AA in fontconfig if you don't like it. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Le Mar 7 avril 2009 14:06, Joerg Sonnenberger a écrit : On Tue, Apr 07, 2009 at 01:37:33PM +0200, Nicolas Mailhot wrote: What has no changed is that apps using core fonts just crash all the time. Sorry, but stupid programmers not doing correct validation of return values is NO ARGUMENT. Of course it is when you have to deal with the fallout (either as the entity providing the crash-prone toolkit or as the support entity for apps that use it) I could also misread your statement as programmers that choose to use core fonts are stupid :p Since a lot of them do not do those validations. This is not something specific to core fonts. Fontconfig-using apps do not crash for lack of fonts, because fontconfig has built-in font substitution -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Le Mar 7 avril 2009 14:52, Joerg Sonnenberger a écrit : On Tue, Apr 07, 2009 at 02:32:38PM +0200, Nicolas Mailhot wrote: This is not something specific to core fonts. Fontconfig-using apps do not crash for lack of fonts, because fontconfig has built-in font substitution Are you *really* sure about that? I haven't tried Firefox 3, but older version definitely crashed if fontconfig wouldn't find fonts. 1. IIRC very old firefox versions used gtk1 and core fonts and crashed like other core fonts users (I run Fedora devel, so my old is relative) 2. I haven't seen any widespread case of fontconfig not finding fonts in Fedora in the past years. I've seen sporadic one-of reports where someone did something stupid, such as making fontconfig caches RO, but nothing remotely like core fonts crashes (and I'm CCed on most Fedora font bug reports nowadays). However googling a bit I see others distros may not be as careful to run fc-cache timely on font install. We do regularly have reports of core font related crashes and they do outnumber fontconfig problems even though as this stage almost all the distro uses fontconfig instead. 3. There are persistent reports of firefox weirdness if fontconfig is updated while a firefox instance is running, but usually mostly cosmetic and not affecting other apps, so I guess Mofo has a buglet somewhere. Restarting firefox cleans up things. 4. pre-release fontconfig versions have bugs as other software and we see them in fedora-devel. Though usually with cosmetic effects only (font mis-selection, not crashes) Mostly, fontconfig users complain font selection heuristics or rendering settings are not as good as they should be. Core font users OTOH have problems just getting their apps to run reliably. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?
Le dimanche 01 février 2009 à 12:54 +, Nix a écrit : On 31 Jan 2009, Michel Dänzer outgrape: I think a big part of the motivation for client side fonts was indeed anti-aliasing, so if you don't want AA and core fonts are faster for you, just use core fonts? That's Not really practical, because they involve different APIs, different font matching mechanisms, and so forth: they aren't really interchangeable. I don't think an attempt to convince the KDE hackers to allow konsole to use core fonts would go very far, not least because core fonts are generally seen as obsolescent From a distribution point of view, apps which use fontconfig almost never present problems (because fontconfig will do all kinds of smart stuff like substituting missing fonts transparently), while apps that use core fonts have a long continuing history of crashing at the slightest opportunity (with users complaining at the distribution instead of upstream). For Fedora 11 we've trying to move all our fonts in fontconfig space, with symlinks to other parts of the filesystem for apps that do not use fontconfig http://fedoraproject.org/wiki/Features/Repackaging_of_Fedora_fonts I think the Fedora 12 cycle will probably start by mass bug-filling against apps that need those symlinks. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Default to use standard fonts and builtin fonts as a fallback
Hi, From a totally human and not technical POW, it would be great if use of core fonts, especially *failing* use of core fonts, resulted in a warning telling people to fontconfig-ify their apps. I'd rather have users pester application authors/ISVs so they move to the current millenium rather than having them hammer xorg and distro lists to make core fonts work perfectly (which was never the case and is unlikely to ever happen at this stage). A lot of old *nix users have totally missed the fact fontconfig happened, and need some education. Regards, -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X12
Le Ven 19 décembre 2008 10:35, Eirik Byrkjeflot Anonsen a écrit : Ah, I see. The problem is when there is something outside the application that wants to change the current locale of the application. Not at all. A German user most definitely does not want the German menus to change to Latin when he writes some Latin quote. The problem is there is a need of a generic cross-desktop-session way for the user to tell the computer here is the language I am inputing, with some coupling to the current xkb layout or input method, and a way for apps to be informed of the current user choice so they load the right spellchecking module, the right font rendering module, tag the text with the right language for document formats that support language tagging, etc. Regards, -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Zoom Support
Le mercredi 17 décembre 2008 à 07:36 +1000, Peter Hutterer a écrit : On Tue, Dec 16, 2008 at 02:49:23PM +, micki _ wrote: I am writing X11 input driver, I would like to emulate Zoom IN/OUT , Is there API , for example to emulate button event i use xf86PostButtonEvent thank you no. zoom is done on the client-side (e.g. compositor) and input drivers don't have anything to do with it. Additionally, there's no specific zoom button, so you have to rely on the client to map button X correctly to the function. Actually MS has defined standard Zoom+/Zoom- keycodes in the HID spec (before mouse wheel zooming took over MS thought a zoom lever in its ergo keyboards would be a great idea), so if they are not part of the 255 crowd xorg currently zaps commanding zoom function should just be a matter of sending those codes, and hoping zooming apps recognize them -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Evdev drops all keyboard events with code 255?
Le Jeu 4 décembre 2008 08:31, Mattias Nissler a écrit : However, xorg's evdev input driver currently drops all keyboard events with code 255 https://bugs.freedesktop.org/show_bug.cgi?id=11227 -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
Le Lun 1 décembre 2008 08:19, David Miller a écrit : But what I spend most of my time doing is figuring out what new default breaks Xorg on my system. This was one of them. The other one was the internal fonts stuff with the X server, which caused me to lose my Emacs international fonts. I don't think it's fair to complain that xorg folks finally started de-emphasizing (not even disabling) the core fonts system more than half a decade after fontconfig was announced and clearly positioned as the target font system (IIRC even SUN was told in no incertain terms it could forget its own next-gen font system because everyone that mattered had adopted fontconfig). If someone complained today foo was only possible in a 2.6 (not 2.4) kernel would you heed it? fontconfig is at least as old as Linux 2.6.0. If you want to complain at someone, complain at software providers which have waited till software started to break user-side to consider the fontconfig transition. Ironically fontconfig was adopted in large part because the core fonts system had major problems with internationalization. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
Le Lun 1 décembre 2008 10:39, David Miller a écrit : From: Nicolas Mailhot [EMAIL PROTECTED] Date: Mon, 1 Dec 2008 09:49:29 +0100 (CET) Ironically fontconfig was adopted in large part because the core fonts system had major problems with internationalization. Ironically you didn't read my posting. I'm not against any of this stuff, I'm against it being done by default which breaks things on existing systems that try to build GIT xorg and help you guys test things. People have waited more than 5 years to make a change in defaults. Be reasonable and admit this is not an hasty change and software had plenty of time to adapt. Distribution folks can be educated on what configure knobs to change. And after some time and things settle, The things have settled years ago. Even Solaris-side. the defaults can change. Which is what happened here. You can say fontconfig had been around long enough, but if something as simple as emacs internationationalized fonts broke, it's obviously not been around long enough to safely change the default. Emacs is about the only FLOSS software that breaks, and only if you don't run the latest versions. xorg people did emacs folks the courtesy of waiting till they had something working even though pretty much everyone else had switched years before. If there is somethign obvious here, is that emacs maintainers didn't made due diligence by any reasonable definition. Even the kernel made major changes (devfs, sysfs, etc) in the time it took for emacs folks to admit there was a problem. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
Le Lun 1 décembre 2008 11:19, David Miller a écrit : From: Nicolas Mailhot [EMAIL PROTECTED] Date: Mon, 1 Dec 2008 10:58:17 +0100 (CET) If there is somethign obvious here, is that emacs maintainers didn't made due diligence by any reasonable definition. Even the kernel made major changes (devfs, sysfs, etc) in the time it took for emacs folks to admit there was a problem. You can run binaries compiled 15 years ago for Linux and they work and run just fine on today's kernels. Yes, sure, tell that to all the people who have OSS-using binaries (not even 15 years old) -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
Le Lun 1 décembre 2008 12:22, Colin Guthrie a écrit : I think the real question here is who is responsible for this. IMHO the core problem is that the Linux kernel console has been left to rot quietly. The main reason evdev/hal does not export a system layout information xorg could use automatically is that layouts on the console are often misconfigured, since: 1. they do not use the layout database where maintenance happens (xkb-config) 2. therefore the optimal layout is often missing console-side, and good-enough for debugging qwerty is used 3. even when there is a good layout, there is often no obvious mapping between the console layout name and the xorg layout name. The result is that since there is no single shared layout X and the kernel use, no layout info is exposed by the kernel infrastructure. (and from a functional point of view there is no reason a key should have a different behaviour in X and the console). BTW now that almost all the X userspace has been converted to use fontconfig and modern TrueType/OpenType fonts, I expect the level of attention fonts in legacy bitmap format receive to drop sharply, which will ultimately lead to problems kernel console-side. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
Le Lun 1 décembre 2008 13:33, Olivier Galibert a écrit : On Mon, Dec 01, 2008 at 01:15:05PM +0100, Nicolas Mailhot wrote: BTW now that almost all the X userspace has been converted to use fontconfig and modern TrueType/OpenType fonts, I expect the level of attention fonts in legacy bitmap format receive to drop sharply, which will ultimately lead to problems kernel console-side. And, as usual, the ones of us that hate antialiased fonts at small sizes can go fuck themselves? As usual, people who care about something are free to maintain it in good shape, since this is how free software works. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
Le Lun 1 décembre 2008 13:44, Olivier Galibert a écrit : On Mon, Dec 01, 2008 at 01:40:57PM +0100, Nicolas Mailhot wrote: As usual, people who care about something are free to maintain it in good shape, since this is how free software works. What is there to maintain, exactly? Fonts are not generated out of thin hair and they need to be updated to keep up with the environment. Environment changes can be changes in encoding standards (unicode is still evolving and even low-level hardware stuff such as USB identifiers uses unicode), changes in font formats (use the same format as everyone else if you want to tap in the common maintenance pool), changes in hardware capabilities (hardware pixel density is not a physical constant and any change there invalidates the existing pool of bitmap fonts). If you think there's nothing to maintain don't complain if maintenance is not done and things break in a few years. Fonts require maintenance just like every other part of the software stack. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
Le Lun 1 décembre 2008 13:59, Alan Cox a écrit : The result is that since there is no single shared layout X and the kernel use, no layout info is exposed by the kernel infrastructure. (and from a functional point of view there is no reason a key should have a different behaviour in X and the console). So load the correct keyboard tables. The kernel is not and never has been a keyboard layout manager. That is a policy item, and the fact you may want differing behaviour and policy for different systems means it needs to stay so. I didn't write the kernel needed to be a layout manager, just that as long as the different bits of userspace (console and xorg) couldn't agree on a common layouting system there would be no chance of the system exposing a setting xorg could just pick at startup. (and exposing a setting is very different from having this setting managed kernel-side) BTW now that almost all the X userspace has been converted to use fontconfig and modern TrueType/OpenType fonts, I expect the level of attention fonts in legacy bitmap format receive to drop sharply, which will ultimately lead to problems kernel console-side. The bitmap fonts don't change so this sounds like complete garbage. Just check the console on any random selection of non-us or uk systems and you'll see the current garbage is the console output. Sure it is not a blocker because all the different encodings agree on the ASCII part, but anything outside the 127 first codepoints has a high probability of being mis-rendered. Even if you want a new bitmap font from a monospace truetype one the complexity of rendering a bitmap font data set is mindnumbing low, trivial and automatable. The problem is not rendering the font data, it's to get the right font data in the first place. You have not-so-trivial problems like the limited number of glyphs allowed in console fonts, the fact 4:3 15 VGA screens are not manufactured anymore, etc -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
Le Lun 1 décembre 2008 14:10, Alan Cox a écrit : All non issues. In case you've not noticed every time you use a vectorised font you turn it into a bitmap to suit a changing variety of hardware and encodings. In case you've not noticed the so-called kernel console userspace is totally unable right now to turn standard vectorised fonts into bitmaps suiting a changing variety of hardware and encodings, and relies on manually pre-processed bitmap fonts precious few people maintain and adapt to environment changes. The day it gains parity with xorg on this front, I totally agree with you there would not be any problem maintenance-side. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
Le Lun 1 décembre 2008 14:31, Alan Cox a écrit : Just check the console on any random selection of non-us or uk systems and you'll see the current garbage is the console output. Sure it is not a blocker because all the different encodings agree on the ASCII part, but anything outside the 127 first codepoints has a high probability of being mis-rendered. You mean you don't know how to work the console or put it in unicode mode. Diddums. I mean this is broken every Fedora release or so just by applying system updates without any user-level intervention. I don't think that if the problem was so trivial the fine Fedora maintainers would keep on breaking it. There are things you can't do in character console mode - arabic is quite tricky, most indian languages are a no-go, but the console isn't designed for that so we don't care. I'm quite aware of the specific needs of those scripts thank you very much, right now the breakage extends to simple latin languages (the last one was romanian I think). The problem is not rendering the font data, it's to get the right font data in the first place. You have not-so-trivial problems like the The font data is out there already thank you. As you keep conveniently forgetting X can already render those fonts to bitmaps suitable for such a screen so the problem doesn't exist except in your mind. If you're saying X is now needed to render the console I think people will object. If you're saying someone could possibly duplicate what X does console-side I don't disagree. However that does not make it a solution one can use today. limited number of glyphs allowed in console fonts, the fact 4:3 15 VGA screens are not manufactured anymore, etc Untrue but rather irrelevant really. The font size in VGA consoles is defined by the hardware on the video card. And the userspace that loads it which is limited to 512 codepoints right now IIRC. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
Le Lun 1 décembre 2008 16:47, Alexander E. Patrakov a écrit : Apriori, there is no sensible default keyboard layout. There could be if the hardware started advertising what actually painted on its keys (and even then many people would want to override it). Since it does not, you're right. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Moving xkbcomp into the server
Le mardi 18 novembre 2008 à 13:36 -0200, Paulo Cesar Pereira de Andrade A bit offtopic, but I think xkb really lacks a tool like xkeycaps http://www.jwz.org/xkeycaps/ Xkb configuration is not something trivial, and a program like that would be very useful. Like this? http://simos.info/blog/archives/747 Interested people can help Simos polish his summer of code project. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
