Re: performance issue questions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Jerry Casiano wrote:

Actually, given the above it brings up more questions, at least for me.

Why are you keeping fifteen thousand duplicates?
Whether they are links or actual duplicates is really besides the point.

And what programs do you require that concern themselves with font filenames and would fail if the filename were to change? Seems like broken behavior.

Most any X program that has the font name encoded in a config file for one, and second, most windows programs that rely on the user to pick a font -- though they won't care about case changes. Probably *most* of them are either case changes, OR some of them that are "shortened".
Do all twenty thousand plus actual font files need to be available to everything at all times?

Unlikely, but I don't know which will break what if I start randomly deleting. I *try* to go through them in batches once in a while, but it's hard to make progress against a collection that's been building for 15+ years.
But I'm sure many of the fonts are ones I could throw out --- IF I knew
which ones they were.
   Soooo... Windows 7 came out ... 5-7 years ago and it could handle large
numbers of fonts (it is not bad at doing some organization).

   Windows *ignores* the duplicates (it recognizes fonts with the same
internal data as being duplicates) and it puts them into families.

   Those 21K font files get reduced into about 4400 different font
faces with many or most having multiple variations.  Have seen some that
seem to have 20-30 variations -- maybe 10"ish" names with various types
of obliques/italics/multiple levels of thickness and stylistic variations.

   Given that, if I'm careless about deleting fonts, I could start
deleting variations from families, which wouldn't be good.

   I'm giving the "raw" numbers from linux, but the font software
builtin to win7 7 years ago organized them into a fraction of the
file numbers by families.  Most are familiar with at least having
4 files/fontface for normal,bold,italic and bold-italic, but for
some fonts they get extended into various weight and variations for
titles or fancy-capitals.
   So even though I have software that can supposedly help me
group things, it doesn't do as good a job as the abandoned(?)
fontmatrix which seemed to do the best job of coming up with
font similarities.

Sorry, I know I didn't answer your questions. But I am genuinely curious about your use case and whether there are workarounds that might be acceptable to you.

Workarounds include technology *growing* to handle larger collections and workloads. I ask about parallel processing -- one point in time converting music from wav->mp3 took > realtime, when flac came along, it was slower, but
cpu's made up the pace to give usually give realtime conversion.  When
parallelism came along, I first wrote a shell script to monitor # of
running conversion progs... very primitive, but eventually wrote a perl
script using semaphores that can have the parallelism specified, yield
about a 30-45 second encode time for nearly any album (single-song albums
are the most likely to hit the limits) on a 12-core (2-CPU) home

   If windows could handle 25K fonts 7 years ago (as some smaller
number of grouped font families), I don't see why solutions today can't
be faster and more capable.

   Why is building a cache so slow (I think windows does it in background
each boot, but given it being closed source, I really have no idea).  What
does building a fontcache entail?  If no file data changes, should it
really need to rebuild the whole cache?  Could it use the time/date stamp
as an indicator for rebuilding a single font -- or if a single font
changes, wouldn't it be possible to only update that font?

   Including the list on the response as was intended...

Fontconfig mailing list

[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux