> On May 26, 2011, 2:03 p.m., Thomas Lübking wrote:
> > > Would there even be any good alternative approaches?
> > Yes, 
> > - properly read the fontconfig (including global settings)
> > - only write settings actually touched by the user
> > - have a checkbox to disable custom font configuration (i.e if not enabled, 
> > store the settings in a private config for later use, but wipe the 
> > ~/.fonts.conf

I don't know about accurately reading all of fontconfig, my impression is that 
fontconfig files are write-only (hence the comment about fickleness -- it's 
like reading in HTML pages and trying to make sense of them programmatically 
for all possible variations of an HTML page). And even if it was done, what 
benefit would you get? How often do you change your font rendering? The only 
thing that would currently make sense to me would be something like Windows 
ClearType Tuner, where you can select the subpixel order and the "thickness" or 
"blurriness" of the rasterization by clicking on a rendering that you like 
best. This could be useful to adapt the rendering to low-quality and/or 
misadjusted displays that can't be manually adjusted for whatever reason. And, 
more importantly, it would improve usability tremendously ("Full hinting? 
What's that?"). Fontconfig needs to be modified to recognize those settings. A 
patch in that direction is in the works afaik as part of Infinality's FreeType 
patches (which wonderfully demonstrate how KDE's font dialog bulldozes over 
carefully crafted font configurations). I was thinking about overhauling the 
current font dialog (and throw out the many fields, but have since defected to 
Gnome/Unity...

Anyway, has this patch finally been commited? It should help with your second 
point. The third point seems good, but a custom config is disabled by default 
anyway. My patch makes sure that this is actually respected. Before, the dialog 
would write a custom config even if the setting was 
do-not-change-the-system-defaults! I'm actually surprised that this bug was 
there for so many years. Annoyed me first during KDE 3.5.x. Maybe nobody ever 
cared because nobody ever changed the default font rendering settings and was 
therefore never hit by the bug, which makes the setting itself questionable ;)


- Nikolaus


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101359/#review3538
-----------------------------------------------------------


On May 25, 2011, 8:11 p.m., Nikolaus Waxweiler wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101359/
> -----------------------------------------------------------
> 
> (Updated May 25, 2011, 8:11 p.m.)
> 
> 
> Review request for KDE Base Apps and KDE Runtime.
> 
> 
> Description
> -------
> 
> I simply removed all code in loading routines that wrote something to the 
> config.
> 
> On a side-note, I'd love to rip out the whole fontconfig configuration 
> completely... I think that the whole modifying-.fonts.conf-approach is too 
> fickle because the system/distribution can set up elaborate 
> hinting/antialiasing configurations and the changes made to .fonts.conf just 
> bulldoze over them. Most people will probably never (really want to) touch 
> those settings anyway (Windows and Mac OS X users at least don't seem to, and 
> they don't appear to be unhappy about it)... Would there even be any good 
> alternative approaches?
> 
> 
> This addresses bug 105797.
>     http://bugs.kde.org/show_bug.cgi?id=105797
> 
> 
> Diffs
> -----
> 
>   kcontrol/fonts/fonts.cpp 0cd2666 
>   kcontrol/fonts/kxftconfig.cpp 9cd04de 
> 
> Diff: http://git.reviewboard.kde.org/r/101359/diff/diff
> 
> 
> Testing
> -------
> 
> - Delete .fonts.conf and see if invoking "kcmshell4 fonts" creates it again 
> without user intervention
> - Delete various match-settings set by the kcm (e.g. hintstyle and rgba) and 
> see if it recreates them while leaving match-settings not deleted untouched
> - Switch anti-aliasing settings between system, disbled and enabled and apply 
> each time, change some aa-settings while enabled and check if they stay there 
> after switching
> 
> 
> Thanks,
> 
> Nikolaus Waxweiler
> 
>

Reply via email to