<p dir="ltr">It's not defensive, it's just honest. I'm not a fontconfig dev or fanboy. And I'm not saying that the library is perfect and needs no improvements either. I just don't see it as a situation that will change anytime soon, unless someone is willing and motivated to put in a lot of work for what certainly seems like an edge case.</p>
<p dir="ltr">As I said originally, I was genuinely curious about the use case, even apologized for not addressing your questions. </p>
<p dir="ltr">Unfortunately your responses don't seem to touch on that at all.<br></p>
<p dir="ltr">In any case, have a good day.</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Nov 24, 2016 4:54 AM, "L. A. Walsh" <<a href="mailto:fonts@tlinx.org">fonts@tlinx.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Jerry Casiano wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, 2016-11-23 at 21:46 -0800, L. A. Walsh wrote:<br>
  <br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Most any X program that has the font name encoded in a config file<br>
for one,<br>
    <br>
</blockquote>
<br>
If you're specifying a font name, then the filepath doesn't matter.<br>
  <br>
</blockquote>
---<br>
   That's true, but its hard to find a utility to rename<br>
the font-filenames according to their internal name.  I did run<br>
across one but it only worked for ascii or maybe western character-set<br>
based names.  Really mangled fonts from other languages.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  <br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 and second, most windows programs that rely on the user to pick a font<br>
    <br>
</blockquote>
<br>
Selecting a font from a list of thousands of families with some<br>
containing 20-30 variations sounds fun.   <br>
</blockquote>
----<br>
   Actually you usually just have to pick the family name and have<br>
style sheets select variations based on the usage.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, the actual filepath wouldn't or at least shouldn't matter there<br>
either.<br>
  <br>
</blockquote>
---<br>
   Didn't say it would.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  <br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Workarounds include technology *growing* to handle larger       <br>
</blockquote>
collections and workloads.<br>
    <br>
</blockquote>
<br>
Sounds like that's the only solution that would satisfy you, so no<br>
point in even trying to suggest changes that might ease the pain till<br>
that happens.   <br>
</blockquote>
----<br>
  Uh.... I mentioned the problem over 2 years ago on this list.  I've<br>
ignore the problem and tried to make due by not touching the fonts<br>
on linux for the most part.  But after a couple of years, it seems<br>
like no progress is being made.  I threw out several questions<br>
that I don't know the answers to -- and you seem to be getting defensive<br>
from the first response, in asking me "why do you have all those fonts" --<br>
rather than giving any answers to the questions -- like whether or not<br>
the 32-bit data is needed on a 64-bit only system, or caching by inode<br>
and storing names.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I mean, if you just have to have 15,000 duplicates and 20,000+ font<br>
files active at all times then it is what it is.<br>
  <br>
</blockquote>
====<br>
   I didn't create the duplicates.  In fact I *used* to try to delete<br>
them, but various programs and sources tended to duplicate them.  Linux<br>
was especially bad in creating symlinks for every font that had spaces<br>
in it -- those were read by other programs that got confused about which<br>
was the real name.  Eventually I stopped trying.   If you want to tell<br>
me font-config can rename all of them to eliminate the dups, that's<br>
great.  Also trying to rename fonts on windows can also be problematic --<br>
as some of them are considered "system files" -- remove them (or rename them)<br>
and your system won't boot.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    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.<br>
    <br>
</blockquote>
<br>
That's interesting...<br>
<br>
Good for them.<br>
That OS would normally slow to a crawl with even a fraction of that<br>
figure.<br>
</blockquote>
---<br>
  That happened in XP somewhat, and win98 had horrible limitations, but<br>
in win7 -- no slowdown except at times when you go to display the whole<br>
list -- can take maybe 30 seconds -- that's tolerable.  12 minutes -- not<br>
so much.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 That's actually the main reason font management tools came to<br>
be, in order to avoid the poor performance and usability caused by<br>
having large amounts of fonts active.<br>
  <br>
</blockquote>
----<br>
   Yes, such tools used to be necessary, but I don't see as many<br>
these days and none that work with the OS.<br>
<br>
<br>
   With 64-bit memory, throwing a Gig or so at a font DB in memory<br>
would be nothing on many machines.  I throw 4-8G at various server<br>
programs to allow them to be fast, but you can't do that as easily<br>
with 32-bit constraints.  Many distros aren't shipping 32-bit binaries<br>
any more.  So my asking if the 32-bit font-caches even needed to be<br>
built on machines not using 32-bit progs for graphics (or anything else).<br>
<br>
Seems like a reasonable question, but instead of any of my questions being<br>
answered I get asked why I should be allowed or supported in having so<br>
many...  If it took 30 seconds to cook the fonts or if it<br>
happened in background -- wouldn't be as much of an issue, but instead<br>
of improvement, I am feeling a defensive posture about even asking<br>
questions about what parts are needed and whether some things are<br>
necessary, or whether or not things could be made parallel.  Those<br>
are reasonable questions.<br>
<br>
So why am I getting what seems to be defensiveness?<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div></div>