Version: (using KDE KDE 3.4.0) Installed from: SuSE RPMs Compiler: gcc 3.3 OS: Linux I try to install 4500 fonts (pfb) as superuser. According to the progress dialog in Kcontrolcenter, the speed in copying those fonts varies between 32 KBit/s and 0. In fact, it took me about five hours to copy approx. 400 files with 17 MBytes. My disk is neither full nor slow.
Well I've just installed 2123 fonts, 104Mb, into fonts:/Personal - which took about 20minutes And while not overlay speedy, this is no where near as slow as 400 fonts, or 17Mb, in 4hours! Mind you these were TTF fonts. Do your PFB fonts have matching PFMs, but no AFMs? If so, then for each font ghostscript is being called to create a corresponding AFM. There's something wrong with the progress bar though, as it only ever got up to about 66%. But all fonts were copied and installed.
My experience was with installing fonts globally. And contrary to your idea, there are NO AFM files. I'm still wondering what is taking so long here.
> My experience was with installing fonts globally. And contrary to your > idea, there are NO AFM files. I'm still wondering what is taking so long > here. I know you were installing as root - but there shouldn't be much difference. I will try installing 2,000 fonts as root some other time. *But* the question I asked you was whether you had PFMs. *IF* you have a PFA (or PFB) for with a corresponding PFM, but no AFM, then when installing, the installer will call ghostscript to create an AFM from the PFA/B and PFM combination. For every 20 fonts installed, then installer calls; fc-cache to recreate fontconfigs cache files, and the calls "kfontinst" to configure regular X and ghostscript. The more fonts you have existing each time these commands are called, the slower they will be. (They still shouldntt be any where near the times you are reporting). How long does an "fc-cache --force" take? Craig.
Just to clarify: When installing a font via the KControl center, you open the KDE file dialog to select the list of fonts to install. After these have been selected, for each Type1 font (.pfa or .pfb) kcmfontinst checks to see whther a corresponding .afm file exists. If a .afm file for a font does not exist (and you have stated they do not), it then tries to see whether a corresponding .pfm file exists. If it finds a .afm or .pfm then this is added to the list of files to install. This list of .pfa, .pfb, .afm, and .pfm files is then iterated through and copied to the fonts io-slave. When the io-slave detects that a Type1 font, or .pfm file, is being installed, it tries to check if an existing .afm is installed. If it does not find a .afm, it tries to create one by calling ghostscript with the pf2afm script (which is part of ghostscript). (See bug report 86660 for the reason as to why this feature was implemented.) So, if you are installing 4,000 Type1 fonts that have no .afm file, but do have .pfm files - then ghoscript is being called for each and every Type1 font being installed. This would explain, to a degree, the slow speed. One way to check this would be to move any .pfm files out of the folder containing your Type1 fonts to install. e.g 1. /home/wibble/SomeType1Fonts/ contains your .pfa, or .pfb, and .pfm files 3. Create a tmp sub folder 2. Move /home/wibble/SomeType1Fonts/*.pfm to /home/wibble/SomeType1Fonts/tmp/ 3. Use the font installer to install your Type1 fonts from /home/wibble/SomeType1Fonts/ This would then force kcmfontinst to ignore the .pfm files - as it does not look in sub-folders. If this improves the installation speed, then it would appear that the calling of ghostscript is what is so slow. [ In case your interested; afm = Adobe Font Metrics, and contains metrics about each character in the font, its size, kerning information, etc. pfm = Printer Font Metrics, these are usually only found on Windows systems, and are not used on unix/linux - which use afm files. Ghostscript is able to create valid afm files by combining the information in pfa/b and pfm files. ] Is it possible for you to email me a selection of the fonts you are tyring to install? If you have 200 fonts that are taking 2.5 hours to install (as you indicate) - then send me these, and I'll see if I can reproduce the error. (But I'd need the *exact* same files - and any .pfm or .afm associated.) ---------- Ignore the progress bar - there's something wrong there, and I will try to fix this. (If it bugs you that much, then please create another bug report - but I am aware of the issue).
To clarify things: - yes, I'm installing only PFB-fonts - yes, for each and every PFB, there is a corresponding PFM If ghostscript is actually run to create the AFMs, they never show up. I suppose that a <filename>.pfb should be going with a <filename>.afm. If that's the intention, something is not working. I tried to follow the process with top, and ghostscript never appeared (fc-cache did, though). Furthermore, I have the impression that the installation speed decreases over time: It starts fairly fast and becomes slower and slower, the more files it has processed. I'll now run fc-cache as suggested and move the PFBs to another directory.
Do you have "pf2afm" installed - try "which pf2afm" If so, for a font named "wibble.pfb" (with a "wibble.pfm" in the same folder), does "pf2afm wibble" create an AFM file? Can you send me, or (preferably) make available via ftp, an example of one of your fonts where the AFM creation is not working? (Or link the files to this bug report) As to things slowing down - that is probably true. As I said before, for every 20 fonts installed, fc-cache is re-run, and X and Ghostscript reconfigured. So, the more fonts you have installed, the more data that needs to be regenerated. For configuring regular X, a file called fonts.dir has to be created. This lists each font file, in a folder, and the encodings it supports. So every time you add a font to a folder, that file is re-created (I do read in the previous contents, so only the new font will need to be examined - but still things will slow down). A similar situation occurs for Ghostscript. [ Plus it was the moving PFMs that you should do, not PFBs! ]
As to pf2afm: Yes it exists. BUT: It works only with <file>.pfb/pfm. What I have here is PFB/PFM (uppercase). This seems to be a counter example of robust programming on the part of the GS people, but so be it. I'll start over the whole installation again and let you know if the behavior changed at all.
OK. Perhaps its Ghostscript complaining about the fonts that is slowing things down. Anyway, for KDE3.4.1 when installing a font the exension will be converted to lowercase, and ' ', ':', or '-' will be replaced with '_' in the filename. So, if this is the case, then it should already be fixed (for KDE3.4.1) by the extension lowercasing.
I'm still at KDE 3.4.0. After having changed all filenames to lower case, I needed approx. an hour to install about 500 files (with the pfms still in place - gonna try that later). I'm now at 700, and fc-cache take about 14 seconds (real time, not sys/user). However, there are still no afm files - at least not in /usr/local/share/fonts, where all the pfbs are copied to. Should I look for them somewhere else? Running pf2afm with any pfb file as input on the command line works as expected: I get an afm file in the current directory. With 713 fonts in /usr/local/share/fonts, fc-cache takes 22 seconds. However, I'm not convinced that its fc-cache that slows everything down. If it were, I should see normal speed for twenty files, a significant slow down and then normal speed again. What I notice is a constantly degrading speed. This can of course be related to the growing Fontmap for GS (its now about 200 KByte) and the re-writing of fonts.dir for every font. At least Fontmap though should be writting fairly fast, since it is sufficient to append to it. fonts.dir is worse, because you need the no of entries at its beginning. 730 fonts - fc-cache takes only about 3 seconds. Weird. It does not really seem to be related to the no. of fonts it reads.
Sorry - you state "with the pfms still in place - gonna try that later"? Do you mean the PFMs were there when it took an hour, or they weren't, and you'll put them there later? If they werent there, then thats why there's no AFMs - as AFMs are only created if both a Type1 and a PFM exist. pf2afm will create an AFM from just a pfb - but it wont have any real usefull information, as it needs the extra info from the PFM. I dont think fc-cache is slowing things down that much. I dont understand "If it were, I should see normal speed for twenty files, a significant slow down and then normal speed again." Whay would it speed up again? The slow down would be after installing font 20, then font 40, 60, etc. Also, there is a timeout, where if there is no activity X seconds after the last reconfigure, and a change has been made, then fc-cache, etc. are called. So the 20 font thing is not the only control for when a reconfigure will happen. Creating GS's Fontmap is not simply a case of appending. In the Fontmap there are aliases that are added, e.g.: /Courier10PitchBT-Bold (c0583bt_1.pfb) ; /Courier10Pitch-Bold /Courier10PitchBT-Bold ; So if you install a font that really has "Courier10Pitch-Bold" as its postscript name (this is what the 1st column is), then the entry above would need to be removed. More fonts => more checking. But should not be that slow. As an experiment, try this: 1. Have all 700, fonts in say /home/wibble/Test 2. Run "kfontinst -gxr /home/wibble/Test" This should create X's fonts.dir in /home/wibble/Test, alter the Fontmap in ~/.fonts, and call "xset fp rehahs" to get X to refresh its font list. How long does that take?
The pfms where still in the same directory as the pfbs. I changed only the case of the filenames. Running kfontinst -gxr with 700 fonts took approx 90 seconds. However, ~/.fonts/Fontmap is still empty (and kfontinst crashed with a segment violation, until I removed /tmp/kfi). xset fp+ <localtestdir> and xset fp rehash do the expected things, and xlsfonts as well as xfd show the newly configured fonts. However, I'm usually working with a font server running on the local machine, so my X fontpath is unix/:7100.
> The pfms where still in the same directory as the pfbs. I changed only the > case of the filenames. Strange, afm generation works for me - even as root. > > Running kfontinst -gxr with 700 fonts took approx 90 seconds. However, > ~/.fonts/Fontmap is still empty (and kfontinst crashed with a segment > violation, until I removed /tmp/kfi). Yeah - the /tmp/kfi was due to mean being brain-dead. Sorry. This will be fixed when KDE3.4.1 is released. Also, as to the Fontmap. The directory has to be known to fontconfig (the list of fonts comes from here), and the Fontmap file is placed into the folder. So kfontinst -g /home/wibble/wobble will only work if ~/.fonts.conf lists ~/wobble - and Fontmap will be placed in ~/wobble > However, I'm usually working with a font server running on the local > machine, so my X fontpath is unix/:7100. Well this "should" be detected by the ioslave, and a SIGUSR2 sent to the font server - which causes it to refresh its font list.
To the reporter: have you checked your /etc/fonts/Fontmap file for duplicate entries and/or inusual growth? This might be the reason of the slowness. I experienced similar slowness during a font installation. See my bug report, #109610. Thanks, Eduardo
Hi, Can you confirm if this is still a problem using KDE3.5.1 (or later)? I've made some changes that should speed up the installation, and removal of fonts.
@ Comment #14 I am running kde 3.5.2 now, on Fedora5, and i have a small problem installing True type fonts, i am using the Control center's "Font Installer" thingy, only problem with it is that it doesn't install any fonts ... It always says this when i want to install new fonts(arial for example): I press add button, select font ...and: A nice dialog box appears, with the caption: "File Already Exists" and contens: An older item named 'fonts:/arial.ttf' already exists size 0 B The source file is '/home/arial.ttf' size 196.0 kb I can Overwrite or cancel, if i overwrite i get the sucess dialog. In the process table i can see kfontinst soaking up 99% of the CPU, after 30 minutes or so i stopped it. The number of installed fonts remains at 74, and a reboot doesn't help, still 74 fonts installed. It used to install those fonts (31 or so) in less than 5 seconds on earlyer versions, now it can't even install 1 font. This may be a separate bug or a Fedora5 Only bug, don't know. I was able to reproduce it on another system running Fedora5 and kde 3.5.1
Very odd! Can you try again, but in the settings dialog - can you disable the "Configure fonts for Ghostscript". Also, can you turn on KDE's debug - via kdebugdialog (just enable '0 - Generic). This should cause kio_fonts to output some debug to ~/.xsession-errors. Then can you send me a copy of that file? [Note, if you are running the installer in KControl via the admin mode, you will need to run kdebugdialog as root] Also, the font-installation wont actually be that much faster - but I have worked on this, and it will be much, much, quicker in KDE4. Craig.
I managed to get the fonts installed by creating a .fonts directory in the home folder and copying all the fonts i need in there. I tried today to delete one font (arial) from kfontinst. I select the font, press the delete button, a dialog appears attempting to delete, apparently sucessfull, the success information box saies i must restart the applications, but the font is still there, and i have a progress bar that stays at 0%, see the attachment, also, kfontinst is soaking up all the CPU again. If i kill it, the progress bar disappears. After 5 minutes or so, i noticed the font to be gone(it really was deleted from .fonts and the font status got updated), but now i can't install it back using kfontinst, same problem about it already existing and being 0 bytes... The font file is valid, i can even use it with openoffice, i'll atatch it tho. And: Running as root Configure fonts for Ghostscript -> disabled Configure fonts for legacy X application->Enabled kdebugdialog->0-Generic-> enabled ~/.xsession-errors -> file doesn't exist, even tried using updatedb + locate, didn't find it.
Created attachment 15814 [details] arial font
Created attachment 15815 [details] Progress bar remains at 0% after deleting 1 font
I reinstalled the arial font by copying into ~/.fonts directory. And i can use it too. With all applications
OK. This is very odd. After installing, and then deleting the font, when you get the font exists but 0 bytes dialog, what is the output of: fc-list | grep -i arial does it list a font? It could be that fontconfig still thinks the font exists. If you run "kcmshell fonts" is the font still visible? Which version of fontconfig are you using? Does "fc-cache -v" produce any errors? As for the debug output, can you try using "kdebugdialog --fullmode", Select Information, Output to "File", and enter a filename. After the above, can you try also disabling "Configure fonts for legacy X application".
after deleting it from control center's "Install Fonts" (withe the same issues as comment #17 ) the regular arial font doesn't show up in kcmshell fontsfc-list | grep arial yields nothing, fc-list | grep Arial yields: Arial Black:style=Regular,Normal,obyčejné,Standard,Κανονικά,Normaali,Normál,Normale,Standaard,Normalny,Обычный,Normálne,Navadno,Arrunta Arial:style=Bold Italic,Negreta cursiva,tučné kurzíva,fed kursiv,Fett Kursiv,Έντονα Πλάγια,Negrita Cursiva,Lihavoitu Kursivoi,Gras Italique,Félkövér dőlt,Grassetto Corsivo,Vet Cursief,Halvfet Kursiv,Pogrubiona kursywa,Negrito Itálico,Полужирный Курсив,Tučná kurzíva,Fet Kursiv,Kalın İtalik,Krepko poševno,nghiêng đâm,Lodi etzana Arial:style=Italic,Cursiva,kurzíva,kursiv,Πλάγια,Kursivoitu,Italique,Dőlt,Corsivo,Cursief,Kursywa,Itálico,Курсив,İtalik,Poševno,nghiêng,Etzana Arial:style=Bold,Negreta,tučné,fed,Fett,Έντονα,Negrita,Lihavoitu,Gras,Félkövér,Grassetto,Vet,Halvfet,Pogrubiony,Negrito,Полужирный,Fet,Kalın,Krepko,đâm,Lodia Font Install form control panel shows me: Arial black Arial, bold Arial, bold italic Arial, italic The font that i deleted is simple Arial (regular) And yes, installing arial with the "Font install" from control center gives me the result that the file exists and it is zero bytes. fc-cache -v yields: #fc-cache -v fc-cache: "/usr/share/fonts": skipping, 0 fonts, 4 dirs fc-cache: "/usr/share/fonts/bitstream-vera": skipping, 10 fonts, 0 dirs fc-cache: "/usr/share/fonts/bitmap-fonts": skipping, 31 fonts, 0 dirs fc-cache: "/usr/share/fonts/default": skipping, 0 fonts, 2 dirs fc-cache: "/usr/share/fonts/default/Type1": skipping, 35 fonts, 0 dirs fc-cache: "/usr/share/fonts/default/ghostscript": skipping, 8 fonts, 0 dirs fc-cache: "/usr/share/fonts/ISO8859-2": skipping, 0 fonts, 3 dirs fc-cache: "/usr/share/fonts/ISO8859-2/100dpi": skipping, 0 fonts, 0 dirs fc-cache: "/usr/share/fonts/ISO8859-2/75dpi": skipping, 0 fonts, 0 dirs fc-cache: "/usr/share/fonts/ISO8859-2/misc": skipping, 0 fonts, 0 dirs fc-cache: "/usr/share/X11/fonts/Type1": skipping, 29 fonts, 0 dirs fc-cache: "/usr/share/X11/fonts/OTF": skipping, no such directory fc-cache: "/root/.fonts": skipping, 30 fonts, 0 dirs fc-cache: succeeded # I created the /usr/share/X11/fonts/OTF directory, but the problem persisted, still coudn't install regular arial font. Also tried to disable "Configure fonts for legacy X application", didn't fix the problem. Everything works fine as long as i manually copy the fonts in the proper directory. Also, i tried to set kdebugdialog --fullmode file output as /root/errors (on all, not just Information) nothing appeared in /root And i am logged in as root, so it isn't a permisions issue. I am thinking this is a Fedora only bug tho, there is an arial font attatched, can someone try to install it with a kde 3.5.1-3.5.2 on a non-fedora install?
Just tied installing, removing, installing under KUbuntu breezy with KDE3.5.1 - and it worked fine. Which version of fontconfig does Fedora have? KUbuntu breezy uses 2.3.2 I can try on KUbuntu Dapper - KDE3.5.2 later.
What do the following produce: 1. kfontinst -x <folder where you placed the font> 2. kfontinst -f <folder where you placed the font> ...i.e. do any of these hang? If the first does, then do either of the folowing also hang: 1. mkfontscale <folder where you placed the font> 2. mkfontdir <folder where you placed the font> Is <folder where you placed the font> listed in /etc/X11/xorg.conf? Is it, or one of its parent folders (eg. /usr/local is the parent of /usr/local/x), listed in /etc/fonts/local.conf, or /etc/fonts/fonts.conf?
kfontinst -x .fonts gives segmentation fault kfontinst -f .fonts gives carrige return mkfontscale .fonts gives carrige return mkfontdir .fonts gives carrige return the problem is here here, at /etc/fonts/fonts.conf: <!-- Font directory list --> <dir>/usr/share/fonts</dir> <dir>/usr/share/X11/fonts/Type1</dir> <dir>/usr/share/X11/fonts/OTF</dir> <dir>~/.fonts</dir> <!-- i see it's missing /usr/local/share/fonts I added it by hand and the font install worked like a charm, delete, add, everything worked PERFECTLY. I added the folder like: <dir>/usr/local/share/fonts</dir> and that fixed everything I deleted the manually added folder and the errors came back(font already exists and it's zero bytes ..). kfontinst -x .fonts still gives a segmentation fault, but that doesn't matter since font install/delete works now.
kfontinst -x .fonts should've been either kfontinst -x /home/root/.fonts kfontinst -x /usr/local/share/fonts .i.e. it needs the complete path to the folder - its only a helper app used by fonts:/, so its quite simple. The "-x" option tells it to configure the folder for X - i.e. it should do something similar to mkfontscale & mmkfontdir. Does kfontinst -x /usr/local/share/fonts crash? If this does crash, can you try it on a folder *just* containing your arial.ttf? The "-f" option should add the folder to fontconfig's files - but again it needs the complete path. So kfontinst -f /usr/local/share/fonts Should add /usr/local/share/fonts to /etc/fonts/local.conf (if you're using fontconfig <2.3), or /etc/fonts/conf.d/00kde (if fontconfig >=2.3). I think its broken at the moment and always adds to /etc/fonts/local.conf even for >2.3, but this is still OK. (/etc/fonts/fonts.conf should not be used as it will be overwritten the next time you upgrade) What are the <dir> contents of /etc/fonts/local.conf and (if it exists) /etc/fonts/conf.d/*.conf ?
kfontinst -x /root/.fonts Segmentation Fault (permission issue?: cannot install system wide from /root folder ?) # kfontinst -x /usr/local/share/fonts doesn't crash, carrige return #less /etc/fonts/local.conf | grep dir <dir>/usr/local/share/fonts</dir> # less /etc/fonts/conf.d/*.conf | grep dir nothing # #less /etc/fonts/conf.d/* | grep dir <dir>/usr/local/share/fonts</dir> <dir>/usr/X11R6/lib/X11/fonts/TrueType</dir> <dir>.fonts</dir> # /etc/fonts/conf.d/ # ls /etc/fonts/conf.d/ 00kde autohint.conf unhinted.conf 10-fonts-persian.conf no-bitmaps.conf yes-bitmaps.conf 40-blacklist-fonts.conf no-sub-pixel.conf 50-no-hint-fonts.conf sub-pixel.conf # it seems all the dirs are in the 00kde file that exists in that directory. the line <dir>/usr/local/share/fonts</dir> added to local.conf and 00kde made me think: it must have been added by kfontinst -f /usr/local/share/fonts, because when i deactivated that line from the main config file, and the error that the file exists and it is zero bytes didn't appear any more. I wonder if kfontinst's first command is to add/delete the fonts, and not to add the folder to the config files, then it would try again and again to make the modification, but doesn't know where the font is... Apparently, fedora5 uses fontconfig-2.3.94 (did a search on rpm.pbone.net)
Got a new problem now, can't turn on antialiasing. I can check the option in control center to use antialiasing, but there is no difference between antialiased fonts and non-antialiased ones, they all look ugly, (choppy, a pain to read). Guess i shouldn't have played around with fonts . . . I deleted all the m$ fonts, but antialiasing didn't return. I logged in a user account(antialiasing turned on in Control Center, of course), but still no antialiasing. Perhaps is time to reinstall kde?
Update on Comment #28 I was able to correct that issue by deleteing the contens of /etc/fonts/local.conf. Here is it's (bad) contens: <?xml version="1.0"?><!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <dir>/usr/local/share/fonts</dir> <match target="font" > <edit mode="assign" name="antialias" > <bool>false</bool> </edit> </match> </fontconfig> It seems this file takes precedence over KDE control center's settings. Is that a bug?
> ------- kfontinst -x /root/.fonts > Segmentation Fault > (permission issue?: cannot install system wide from /root folder ?) So whats in ~root/.fonts? and whats the permission of this? Cant think it'd be a permissions problem, as (I assume) you're running kfontinst as root. But, the installer, when run as root, will (should) not install fonts into ~/.fonts - it should use /usr/local/share/fonts > # kfontinst -x /usr/local/share/fonts > doesn't crash, carrige return Good!:-) So I wonder where the 100% cpu usage was coming from? > #less /etc/fonts/local.conf | grep dir > <dir>/usr/local/share/fonts</dir> ...but you said you had to add "/usr/local/share/fonts" to /etc/fonts/fonts.conf to fix the add/delete issue. > made me think: it must have been added by kfontinst -f > /usr/local/share/fonts, Yup - that's what the -f does. But, when fonts:/ is run (the kcontrol module is just a front end for fonts:/) it checks fontconfig's dirs, and should add /usr/local/share/fonts if it is not already listed. Or it will use any sub-dir of /usr/local/share/ that is listed in fontconfig's paths. > because when i deactivated that line from the main > config file, and the error that the file exists and it is zero bytes didn't > appear any more. When you deactivated it the error disappeared? You said you needed the line to stop the error... > I wonder if kfontinst's first command is to add/delete the > fonts, and not to add the folder to the config files, then it would try > again and again to make the modification, but doesn't know where the font > is... Apparently, fedora5 uses fontconfig-2.3.94 (did a search on > rpm.pbone.net) Hmmm... 2.3.94 is a beta release for 2.4. As you're using "fontconfig-2.3.94", do you also have the folling error: https://bugs.kde.org/show_bug.cgi?id=124007 ...which I think fontconfig 2.3.95 fixes.
> I was able to correct that issue by deleteing the contens of > /etc/fonts/local.conf. Here is it's (bad) contens: > <?xml version="1.0"?><!DOCTYPE fontconfig SYSTEM "fonts.dtd"> > <fontconfig> > <dir>/usr/local/share/fonts</dir> > <match target="font" > > <edit mode="assign" name="antialias" > > <bool>false</bool> > </edit> > </match> > </fontconfig> > > It seems this file takes precedence over KDE control center's settings. > Is that a bug? Yup it is - and I fixed that about 2 days ago! So it should be in 3.5.3. It occurred as someone else modified the kxftconfig files shared between the fonts kcontrol module and the font installer - but forgot to check the behaviour of the 2 modules. I've now fixed this so that when the installer uses this class, the antialias stuff is not used/set/whatever.
I can reproduce the error( tho one about zero bytes..) by de-activateing the <dir>/usr/local/share/fonts</dir> line from both the /etc/fonts/fonts.conf and /etc/fonts/local.conf I am curious to see if this a Fedora only issue. If you get a similar error, look at the processor usage. As long as the <dir> line in present in one(doesn't matter which one) or both files, i have no problems installing/deleteing. As for the segmentation fault: i traced it to a corrupt fontfile: martlett.ttf Don't know how it got corrupted, but when i put it in the .fonts directory, kfontinst -x /root/.fonts gives a segmentation fault. If i take it out, all is well. Regarding bug #124007 i have no problems viewing non-installed fonts in konqeror's "preview" and kfontview, i think i never did, not even when fedora5 was just 4 days old.
As for the speed of installation, there's not much I can do for KDE 3.5.x, and KDE4's installer is *much* faster.