|
2006-02-25 13:26
|
prefences_general_with_font_face.png (54,890 bytes) |
|
|
Why should it be up to us to fix distros' problems? They should learn to package things correctly. |
|
|
hmm..,this is not about fixing some distros problems (this has nothing to do with a distro, but with different desktop environments). This is about adding some more usability to the Scribus GUI and making Scribus a better, more DE/distro/OS independent application. There already are font size settings for menus and palettes, adding font face to them would additionally allow e.g. a Chinese, or Russian, or Polish user to switch to an appriopriate font face containing their national glyphs, if they decide to switch Scribus to other language than their desktop environment language and don't want to see lots of squares. Hope this helps to clarify my reasons :) |
|
|
Reminder sent to: ringerc, I'm adding you to this rfe, because we've already discussed some of the problems in RFE 0002751 |
|
|
I don't see why we should have to produce this (while it is easy), when the distros should be packaging qtconfig for users to config their apps, AS WELL AS those distros providing a decent initial setup for them, particularly the Gnome based ones. I'm not sure I see why one use would want to have one font for the GUI and therefore support for native glyphs and not have them in their other apps. |
|
|
- case 1 (real life): my win desktop at work is German, because i live and work in Austria, I want to have Scribus in Polish (russian, chinese), without reconfiguring the whole desktop - case 2 (real life): translating the GUI: i can switch the lang from within the Scribus with the great feature of yours :), but I have to go to qtconfig to switch the fonts to actually see the national glyphs -- why shouldn't it be done easier? |
|
|
Ok, I can agree with case 1, but as you are not Austrian, why not run your desktop in Polish? I'm not sure how real life case 2 is for non translators tho.. maybe it is, maybe not. |
|
|
This should not be necessary. Qt does, or should do, glyph substitution when glyphs are unavailable in the primary selected font. Is this not happening in your environment? |
|
2006-04-11 14:09
|
european_desktop_chinese_scribus.png (33,801 bytes) |
|
|
ringerc,i've uploaded a screenshot of my win32 desktop to demonstrate one of the situations, where the possibility to choose the Scribus GUI font would be very useful (see euroepean_desktop_chinese_scribus.png). Understandably, such language combinations can be plenty :) |
|
|
IMO that's a Qt issue, possibly a Qt bug. Qt is supposed to do glyph substitution to ensure that text in the UI can be displayed correctly. It is evidently not doing that correctly on win32 (maybe trying too hard to use native menus etc when they lack the needed functionality?). Scribus should not need to add extra preferences to accomplish this. The right behavior is for an appropriate font to be used automatically, preferably with glyph substitution done where required. Adding preferences should be a last resort if no better fix can be found. |
|
|
I've seen this 3 times so far: -- ubuntu with gnome, where pl glyphs where replaced by squares, although the gnome desktop was pl ans system wide fonts were installed (running qtconfig solved this) -- live dtp cd (same behaviour, fonts with pl glyphs available, but i couldn't point Scribus to them) -- now win32 with rather exotic fonts:) ringerc, even if this is a qt issue, you are assuming, that the system wide font containing the missing glyphs is available (which needn't be a case, this could be a font from user's home order) and that qt knows for better which glyphs to use as replacement (what i saw on ubuntu, was rather horrible). I would suggest, let qt do this job, but if it fails, give the user the opportunity to correct it to his taste. |
|
|
Could somebody provide an example of what 'qtconfig' is changing; for instance, their before and after versions of '/etc/qt.rc' or similar file. If Scribus isn't coming with sane configuration defaults out-of-the-box in Ubuntu, then that's a bug and we'd like to fix it in Ubuntu. (A user should not have to configure their software in order to make it useful!). AFAICT 'qtconfig' is not more of a control panel of customisation utility; can we an intelligent that this utility might produce included by default? Could somebody confirm that this bug is actually about whether the Qt font rendering services perform "glyph substitution" for missing characters automatically. |
|
|
a) qtconfig should be included in the qt package on debian and ubuntu so users with qt apps can configure them to look like their gnome interface, or the configuration of the gui should have an option to apply the settings to qt based apps too. b) this bug has nothing to do with glyph substition, it is about providing a decent GUI for pure Qt apps on debian and Ubuntu without the user needing to configure them. c) Yes you could probably include a decent qtrc to set the fonts as appropriate based on the selected ones in gnome however when the user changes them, they need to be able to change them for qt apps too. |
|
|
Reminder sent to: Peter, you've got a still untouched stock Ubuntu, I presume -- could you provide here an example of /etc/qt.rc before and after a decent facelift with qtconfig? Paul Sladen would need the latter to incude it into Ubuntu. I can't do it myself, I'm on Kubuntu. |
|
|
Ok, with a fresh install of Hardy in VM with KDE4, everything works perfectly and I can use non-Latin fonts, and starting Scribus in Polish, along with other Latin2 langs works fine. That said, I maintain, along with cbradney that this is a missing dependency on ubuntu when Scribus is installed. Here is the description from synaptic: |
|
|
The Qt3 Configuration Application The Qt Configuration program allows end users to configure the look and behavior of any Qt3 application. It is mostly only necessary on systems which don't run KDE because the KDE control center already covers this configuration automatically for the users Qt3 applications according to his desktop settings in KDE. However, if you need to run CJK-fonts or other non-latin scripts, you will most likely want to install this package. |
|
|
(Please correct me if these notes are wrong). Scribus doesn't pick the font for the menus. Qt (the widget set), uses the the font in the .qtconfig configuration file (or the default). Scribus must not require additional configuration *just to work*. It 'qtconfig' is making a change to a text-file, we can include that change in the first place. |
|
|
> Scribus doesn't pick the font for the menus. Correct > Qt (the widget set), uses the the font in the .qtconfig configuration file (or the default). qt.rc or qt3.rc depending on packaging by distro > Scribus must not require additional configuration *just to work*. For someone on a Gnome or XFCE desktop without qt3-config, I am not sure how this can be done at all. As far as I know there is no control center applet to handle themes or UI fonts like kcm-gtk does in KDE. > It 'qtconfig' is making a change to a text-file, we can include that change in the first place. The problem with just adding a qt.rc is there will never be one size fits all which can work. What is appropriate for a CJK or Indic user might not be useful for me. The earlier issues with Lohit are indicative. Likewise picking Bitstream Vera over DejaVu would also be bad for Slavic or Cyrillic languages. What I cannot understand is why there is so much resistance to adding a relatively small package as a dependency. qt3config is automatically added to any qt3 install on Fedora, Suse and Mandriva. We also include it in our Win32 packages, even if it is not strictly required. |
|
|
> For someone on a Gnome or XFCE desktop without qt3-config A much higher-level issue. If a user clicks "?????????? Scribus" ("install Scribus") then that is what should happen. There should be no further configuration (required) for basic operation *at all*. Package dependencies take care of required libraries; package install script automate special cases. Imagine getting the keys to a new car and finding that it has no steering wheel fitted. If the _toolkit_ is picking a font that does not have characters for the current locale, there's two places to fix this: (a) the font that the toolkit is picking (b) the (coverage of) glyphs present in the font being picked. If manual changes are necessary, I would like to automate those changes for everyone. To do that, we need to collective agree on two things: (a) What overrides/changes are required. (b) When the changes need to be [automatically] applied. |
|
|
(Ha, it's a bit difficult to give examples of i10n font issues when the bugtracker can't handle UTF-8 examples!) |
|
|
FWIW, reported the issue with Mantis (this bugtracker) not handling UTF-8 at: http://www.mantisbt.org/bugs/view.php?id=9118 |
|
|
Well I have done some testing with Hardy running under ubuntu desktop /gnome and every language I picked came up with no missing glyphs. So, in this case, I am include to close this bug. It seems the updates to font packages seemed to have help this a lot. JFYI, I have not seen this issue on other distros I have run Scribus on. |
|
|
My take on this is that qt apps require qt, and qt apps' users' require to be able to configure them, if the system they use cant do it for them. Therefore, qtconfig should be a dependency of qt itself - ie dont split the damn thing out in the first place. |
|
|
Closing It is not our bug |
- Anonymous
