Bug 2129399 - Postscript standard symbol font is not looked up correctly
Summary: Postscript standard symbol font is not looked up correctly
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: fontconfig
Version: 38
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Akira TAGOH
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-09-23 15:29 UTC by rgb
Modified: 2024-03-18 10:05 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)
Delta xfig source (297 bytes, image/x-xfig)
2022-09-23 17:00 UTC, rgb
no flags Details
Resulting Delta.fig EPS file (1.92 KB, image/x-eps)
2022-09-23 17:01 UTC, rgb
no flags Details
Tex source that displaces the "figure" (181 bytes, text/x-tex)
2022-09-23 17:02 UTC, rgb
no flags Details
Postscript produced from latex source and dvips (18.33 KB, application/postscript)
2022-09-23 17:02 UTC, rgb
no flags Details
PDF produced by ps2pdf, no arguments, from Delta.fig -> Delta.eps -> Delta.tex -> Delta.ps (2.70 KB, application/pdf)
2022-09-23 17:03 UTC, rgb
no flags Details
Screenshot of the problem (17.23 KB, image/png)
2022-09-23 17:09 UTC, rgb
no flags Details
Screenshot of fonts on my Fedora 34 system after ps2pdf (works, with Vera-Sans) (101.23 KB, image/png)
2022-09-26 17:41 UTC, rgb
no flags Details
Screenshot of font used by evince when failure occurs. (104.75 KB, image/png)
2022-09-29 19:41 UTC, rgb
no flags Details
Entire greek/symbol set in noto-sans-regular (123.41 KB, image/png)
2022-09-29 19:54 UTC, rgb
no flags Details

Description rgb 2022-09-23 15:29:49 UTC
Description of problem:  In between F34 and F36, the default behavior of ghostscript changed such that e.g. scaled greek text in xfig-generated graphics displays on screen in evince as an empty box after being included in a latex document that is then compiled and turned into a PDF with ps2pdf.  On all of my older systems from time immemorial, evince and other browsers  (correctly) display all characters and graphics and text in the pdf ps2pdf (a "distiller" shell for ghostscript itself) produces. This has broken all of my build scripts and production sequence for e.g. writing textbooks and quizzes and exams.

The problem is solveable by adding -dPDFSETTINGS=/printer to the ps2pdf command line in the build process, clearly indicating that this is the specific component setting that somehow changed in either 35 or 36, but according to the ghostscript documentation, it should not be necessary -- ghostscript should "do the right thing", which in the modern era especially where storage is infinitely cheap, should be to maximize resolution and embedding unless specifically told to do otherwise.

Version-Release number of selected component (if applicable): ghostscript-9.56.1-2.fc36.x86_64



How reproducible:

Not sure.  I have only one F36 system running at the moment, and am hesitant to boost my two F34 systems unless/until this (for me) mission-critical bug is resolved.

Steps to Reproduce:
1.  Generate a figure using xfig containing (e.g. $\Delta$ (capital greek delta).  Save the figure and export it into EPS.  If evince is used to examine the EPS file, the delta is still there correctly displayed.
2.  In a short latex source file, use \includegraphics{} to display the figure.  Compile to dvi -> ps.  In the resulting ps file, the Delta is still correctly displayed by evince.
3.  Convert the ps to a pdf with e.g. ps2pdf test.ps, with no arguments.  
4.  Display the resulting test.pdf with evince.  The Delta character does not appear -- only an empty box.  If you repeat step 3 and 4 with -dPDFSETTINGS=/printer, it displays normally.

Actual results: evince displays empty box for some, but not all, greek characters.


Expected results: evince displays perfectly rendered figure


Additional info:  Interestingly, the delta is there in some PDF browsers but not others.  The integrated firefox pdf browser displays it, for example, if a pdf that does not display correctly in evince is accessed via firefox.  I haven't the means to determine if the actual problem is evince instead of ghostscript, but it is definitely solved by the additional setting above, suggesting that it is ghostscript.

Comment 1 Michael J Gruber 2022-09-23 15:43:09 UTC
Thanks for the report.

There are multiple steps involved: xfig export to eps/import into latex/compile to dvi/convert to ps/convert to pdf

Are you doing all of these steps on F36, or only the last one so that it really is the last step which makes the difference? (It could receive different input on F36 already.)

Also, a minimal example would be good, because there are choices involved (fonts, latex document class etc.), and the resulting PDFs on both F34 and F36.

Comment 2 rgb 2022-09-23 17:00:35 UTC
Created attachment 1913855 [details]
Delta xfig source

Comment 3 rgb 2022-09-23 17:01:09 UTC
Created attachment 1913856 [details]
Resulting Delta.fig EPS file

Comment 4 rgb 2022-09-23 17:02:01 UTC
Created attachment 1913857 [details]
Tex source that displaces the "figure"

Comment 5 rgb 2022-09-23 17:02:39 UTC
Created attachment 1913858 [details]
Postscript produced from latex source and dvips

Comment 6 rgb 2022-09-23 17:03:32 UTC
Created attachment 1913859 [details]
PDF produced by ps2pdf, no arguments, from Delta.fig -> Delta.eps -> Delta.tex -> Delta.ps

Comment 7 rgb 2022-09-23 17:09:21 UTC
The chain of documents above were produced by xfig (just Delta in various sizes).
Delta.fig is exported to Delta.eps (I did it inside xfig, but fig2dev does the same).
Delta.tex is a barebones latex shell that includes/displays Delta.eps.  I actually have used epsfig
as well -- no difference in the result -- but \includegraphics is a bit simpler to use.
Delta.dvi I did not include, but I ran straight latex Delta.tex to make Delta.dvi
Delta.ps was produced by dvips Delta.dvi, no other arguments  As you can note, even with evince Delta.ps
correctly displays four Deltas in various font sizes.
Finally, I ran ps2pdf Delta.ps, no other arguments, to produce Delta.pdf.  Before the 34->36 upgrade I 
performed a few weeks ago, this would display more or less identical to  Delta.ps.  It currently displays,
with evince Delta.pdf, with nothing but boxes.  I'll upload a screenshot of this in a second.

Comment 8 rgb 2022-09-23 17:09:59 UTC
Created attachment 1913860 [details]
Screenshot of the problem

Comment 9 Michael J Gruber 2022-09-23 20:36:24 UTC
Thanks a lot!

The resulting PDF uses "Symbol", which is one of the 14 "standard fonts" and therefore not embedded (because postsript devices are required to have them). evince displays this information in properties/fonts,

Would you mind checking this on F34? I.e., does the PDF produced on F34 embed the font?

I suspect that your /printer PDF settings solve the problem because
- this sets EmbedAllFonts
- and evince/poppler need that on F36

Note that even with -dNEWPDF=false, standrad fonts are not embedded.

Comment 10 rgb 2022-09-26 17:39:25 UTC
OK, that was the hint needed to at least partially resolve the problem.  I attach a screenshot of the result.  The "broken" PDF substitutes bitstream-vera-sans for type 1 symbol (and, presumably attempts to embed it).  For reasons unknown, while doing a bog-standard "upgrade" from F34 to F36 (in one step, sure, but still...:-) bitstream-vera-sans disappeared.  When it is missing, ghostscript/ps2pdf substitute noto-sans-regular for Type 1 symbol, which actually DOES have many of the characters but for reasons unknown to humanity, is missing $\Delta$ (capital delta in latex source).  I actually tested for other missing capital greek characters and it HAS most of them!

So, is this a bug in non-sans (missing Delta and at least check for all others)?  A bug in the fedora upgrade process (or human error where I missed that the font had disappeared or was not installed automatically as a dependency)?  A bug in xfig's rpm dependencies, where perhaps they ought to add bitstream-vera-sans-all to the dependencies to ensure that a valid type 1 font symbol font is available for embedding?  A bug in ghostscript's dependencies ditto?

I'm inclined to think noto or ghostscript.  After all, evince displays Delta.ps (latex->dvips output) perfectly, and it is nominally ghostscript's responsibility to either embed a font with all of the characters or at least complain about missing fonts.  Of course, since noto PROVIDES the missing characters, just not Delta, how is gs going to know that Delta -- and possibly only Delta -- is missing from noto?

In any event, a simple fix on my end that is more robust than just aliasing ps2pdf to include the /printer pdfsetting to force embedding of type 1 presumably directly is to install bitstream-vera-sans-all, so I added it explicitly to my install script that I run post bare metal install to put on all of the rpms that I require for my workflow and that aren't in fedora workstation.  It probably IS installed there automagically as a dependence of something I use or in the workstation install, but the upgrade dropped it for reasons I'll likely never know and don't plan to try to duplicate, because all of this works transparently on my other F34 laptops and they definitely have bitstream-vera-sans and gs selects it as the preferred Symbol font in ps2pdf (see below).

It would be great if you would pass this on to really fix it -- entropy has a way of creeping in over time if you don't constantly fight back -- but in the meantime, MY problem is fixed and I thank you -- your hint was exactly what I needed, and I wasn't aware of that feature of evince->properties->fonts acting on PDF files (very useful indeed!).  By the way, curiously the F34 fonts on my F34 system(s) appear to be versioned fc33.  ???

Last metadata expiration check: 0:20:09 ago on Mon Sep 26 13:13:12 2022.
Installed Packages
bitstream-vera-sans-fonts.noarch                 1.10-41.fc33            @fedora
Available Packages
bitstream-vera-sans-mono-fonts.noarch            1.10-41.fc33            fedora 
rgb@lilith|B:1001>

Comment 11 rgb 2022-09-26 17:41:12 UTC
Created attachment 1914412 [details]
Screenshot of fonts on my Fedora 34 system after ps2pdf (works, with Vera-Sans)

Comment 12 rgb 2022-09-26 17:43:44 UTC
(In reply to rgb from comment #10)

> So, is this a bug in non-sans (missing Delta and at least check for all

that is, "noto-sans", sorry.

Comment 13 Michael J Gruber 2022-09-26 19:30:20 UTC
I am pretty sure now that ghostscript has nothing to do with this at all:

If I look at your eps, ps and pdf directly (postscript source) then none of the files "contains" a font. All of them reference "/Symbol", one of the standard fonts which are supposed to be "there" on any standards conforming postscript device. In particular, ps2pdf (gs) without any special options does not do any substitutions or embeddings, either. I'm confident this is the same on your F34-produced pdf!

Whatever displays the eps, ps or pdf has to look up that font ("findfont" in ps). And what it finds depends on the environment: installed fonts and font config which defines substitutions such as what is "serif", "symbol" etc. "Symbol" is a font with a very special encoding, and so some characters will be "off" when the substituted font uses a different encoding.

Since you are a LaTeX user: You might be better off using TeX fonts for maths greek, though I don't know your exact use case. Xfig has different export modes for that, in particular the combined PDF/LaTeX mode which allows you to use pdflatex and skip ps2pdf altogether. Again, this might not fit your use case.

As for the f33 packages on f34: This is not uncommon. And while those fonts happened to be used by default by xfig, it's really a standard postscript font (which does not require embedding) which xfig used, and there is is no reason to install one by dependency. The resulting ps, pdf are correct - it's the viewing end which has to make sure to view those files on a "compliant" device. That's one more reason not rely on this and use other fonts in xfig which get embedded and thus "transported" to the viewing end. Or else make sure they all have urw-base35-standard-symbols-ps-fonts and there is no other symbol named font which is found first.

So, unless ps2pdf produces a different pdf on F34 (I don't think so), I suggest closing this as not a bug.

Comment 14 rgb 2022-09-26 21:59:11 UTC
ps2pdf has some advantages over pdflatex in terms of embedded figures, although none are insurmountable.  I've used both, but ps2pdf has up to now been more reliable especially with \includegraphics -- I've more or less standardized on EPS inputs for all graphics and have scripts our octave output tuned appropriately.

I agree that it isn't an xfig, latex, or dvips bug, but it isn't clear that it isn't an evince bug, or at least something worthy of a warning.  Further experimenting shows that if I remove bitstream-vera-sans then a PDF that displays fine using bitstream-vera-sans displays the empty boxes for Delta and evince reports that it is now using noto-sans (which is apparently missing the Delta although it has everything else I've tested).  However, if I create the pdf using -dPDFSETTINGS=/printer, then the PDF displays correctly in evince, which now reports "Symbol, Type 1C, Encoding: Custom, Embedded subset" under properties->fonts.  Using /printer apparently forces the embedding of the font.

So, according to your second paragraph, a functioning /Symbol font should be "there" on a conforming postscript device, and evince SHOULD be a conforming postscript device (and in fact does correctly display the Delta character in the postscript output from dvips!) but it seems to use alternative system fonts instead of the type 1 fonts xfig currently uses.

I'm perfectly fine with you closing it -- if anybody else encounters the problem, and reports it, this report will be there to point them in the right direction and provide them with at least two ways of repairing it (embed all fonts, something I have to do sometimes anyway as publishers etc sometimes require this, and check to make sure that e.g. bitstream-vera-sans is installed).  But I still think that SOMETHING is not quite right in this.  In particular, if evince requires access to a fully functional /Symbol font in order to be compliant, and bitstream-vera-sans (or whatever) IS fully functional but other fallbacks (like noto-sans) are not, then either bitstream-vera-sans should be an evince dependency, OR evince should use type 1 fonts directly, or -- something.  

Failing to display correctly on a file that as you note is perfectly correct -- I compared strings output on both ps and PDF images, and agree that what ghostscript does hasn't really changed the result 34->36 -- is still a bug, just not a ghostscript bug (and one that one can -- with considerable difficulty --  work around by descending into RPM hell and figuring out what is missing the hard way). The whole POINT of RPMS and yum->dnf is to eliminate having to figure out what is missing by this kind of detective work.  I'm actually an "old guy" (using Unix from back in the 80's, linux from maybe 1994 on) and can usually figure stuff out, but a whole lot of users will just throw up their hands and conclude "Fedora/RH is broken" long before they get there.

Of course, fonts have always been a serious problem from waaaay back, especially scalable fonts that can accommodate variable resolution displays.  xfig actually broke a few years ago because the X11 fonts it was using were finally permanently obsoleted -- I helped report that and was enormously happy when it got beautifully fixed, although (sigh) it still doesn't handle scaling and symbol placement perfectly so that what you see in xfig itself is precisely what you get when you display or print out the result somewhere else (double sigh). One day it would be lovely to have it all comprehensively fixed, but I suspect that I'll be dead (like I said, "old guy":-) before that happens.

Thanks for your help!  It really did help me figure out how to fix the problem so my production laptop is functional again (and I can finally think about upgrading my two or three alternative production machines that I keep in different places).

Comment 15 Michael J Gruber 2022-09-27 11:46:52 UTC
Thank you for being persistent :)

So, on F36 I have working (delta shows):
mupdf Delta.pdf
zathura Delta.pdf (with th mupdf backend)
google-chrome Delta.pdf
firefox Delta.pdf
gimp Delta.ps
zathura Delta.ps
evince Delta.ps


Not working (wrong symbol shows):
gimp Delta.pdf
evince Delta.pdf

So, this is most likely a poppler issue, which is the library that evince and gimp use for pdf. (zathura-pdf-poppler will fail, too, I bet)
In conclusion I'll reassign:

The issue seems to be font lookup in poppler for the postscript symbol standard font.

Comment 16 rgb 2022-09-27 12:06:04 UTC
No, thank YOU for being so tolerant and not saying "persistent PITA":-)

Evince is pretty important, at least to me.  I spend a good chunk of my life working it as I craft content for my physics courses and books.

Thanks again, and I will leave you in peace...;-)

Comment 17 Marek Kašík 2022-09-29 16:50:26 UTC
I had a look at this today and here are my observations so far.

The font which does not work on F36 for me is "Noto Sans Regular", if I remove it then Evince shows me the PDF correctly.
If I force Evince on F34 to use the "Noto Sans Regular" by removing all other candidates then the issue shows there too.
If I install "bitstream-vera-sans-fonts" on F36 then it starts to use this font and shows the correct glyph.

Looking at bugzilla, there is something similar to this issue although the characters they report as missing are really missing in the font - https://bugzilla.redhat.com/show_bug.cgi?id=2088665.
And also something similar in poppler upstream issue tracker but this was resolved by a configuration on user side - https://gitlab.freedesktop.org/poppler/poppler/-/issues/926.

Could you confirm that the font which substitutes "Symbol" font in Evince is "Noto Sans Regular" on your F36?

I'll try to find out why it does not work with the "Noto Sans Regular".

Comment 18 rgb 2022-09-29 19:41:30 UTC
Created attachment 1915083 [details]
Screenshot of font used by evince when failure occurs.

Yes, it is precisely Noto-Sans-Regular.  And I concur -- if bitstream-vera-sans is available, it uses that instead (which works).  Otherwise I can force ps2pdf to embed Type 1 symbol with -dPDFSETTINGS=/printer and it actually WORKS works, where evince uses the T1 Symbol instead of any external font.

Comment 19 rgb 2022-09-29 19:53:36 UTC
See screenshot uploaded above, in case the upload/attachment isn't obvious.

Just to help you in your search -- I just used xfig to generate a graphic containing abcd....xyz and ABC....XYZ, all changed to the symbol font -- pretty much "all" of xfig's symbol collection, then latex->dvips->ps2pdf'd it and displayed it in evince.  I'm about to upload THAT screenshot above.  All characters display correctly (AFAICT) EXCEPT
capital Delta.  This may be a simple bug in the noto-sans-regular font itself.  I don't know how it is built -- metafont? -- but this probably needs to be fixed independent of the issue with evince font selection.  It sounds like evince does exactly the right thing if there are NO substitute fonts, so why does it use substitute fonts at all when T1 Symbol is available?  I'm also going to try your trick of removing both bitstream-vera-sans and noto-sans at the same time just so see what happens when they are both gone.

rgb

Comment 20 rgb 2022-09-29 19:54:23 UTC
Created attachment 1915084 [details]
Entire greek/symbol set in noto-sans-regular

Comment 21 Michael J Gruber 2022-09-29 20:13:08 UTC
It is still strange that poppler seems to resolve the font lookup differently compared to all the other tools (independent of a possible bug in noto-sans-regular or its fontconfig).

Comment 22 Marek Kašík 2022-09-30 18:27:33 UTC
Thank you for the info. Looking closer at this, the font "Noto Sans Regular" does not include "Delta increase" character (together with other mathematical symbols like "for all", "partial differential", ...) but it does include "Greek capital Delta" character. The "Delta increase" character has unicode U+2206 where the "Greek capital Delta" has unicode U+0394. The other fonts seem to have both.

Interestingly, if I change "/Delta" to "/Deltagreek" in "/Differences" array in the encoding of the font inside the PDF then the greek Delta shows up. So maybe the encoding is wrong here. I'll need to have look at how the encoding is created next week and whether the use of "Delta" vs "Deltagreek" is specified anywhere.

Comment 23 Marek Kašík 2022-10-03 13:47:29 UTC
I think that this is an issue in fontconfig. Poppler asks it for "Symbol" font (via equivalent of "fc-match Symbol:lang=xx") and it returns the "Noto Sans" on second place but it does not have the coverage for math symbols which should be in "Symbol" font. For example the third place ("DejaVu Sans") is much better candidate. Poppler rejects the first candidate as it is a "t1" font ("Standard Symbols PS").
I have to admit that poppler does not set "symbol" to "true" when generating the FcPattern but it does not change the result.

It does not seem that poppler's upstream would introduce a special handling of "Symbol" font when querying fonts - https://gitlab.freedesktop.org/poppler/poppler/-/issues/1253 and https://gitlab.freedesktop.org/poppler/poppler/-/issues/926.

I'm reassigning this bug to fontconfig.

Comment 24 Akira TAGOH 2022-10-04 08:16:44 UTC
Not exactly. "Symbol" isn't a sort of generic alias family name such as sans-serif. fontconfig just tries to find out a best font against the request where may contains "Symbol" in family name. that is almost equivarent to find out "Cantarell" as a desktop font in GNOME. If not, trying to pick something up by other conditions then.

In that sense, that could be said that we are *just* missing a "Symbol" font. This isn't a sort of bug.

If we are going to deal with "Symbol" without any special handling, thus, we just need to add a substitute config to the proper font package which has enough coverage or metrics compatible for "Symbol".
To be convenient, we could add it into fontconfig but it won't fix any issues without real fonts. so we should find out any candidate font packages for that instead of doing something in fontconfig.

Comment 25 Michael J Gruber 2022-10-04 12:07:44 UTC
Yes, this is about looking up the font, or the fontconfig coming with some fonts.

I'm still wondering though how the others (mupdf, firefox etc.) look up the font to get a different answer. Do they go through fontconfig but filter the results differently?

Comment 26 Marek Kašík 2022-10-14 12:31:56 UTC
(In reply to Akira TAGOH from comment #24)
> Not exactly. "Symbol" isn't a sort of generic alias family name such as
> sans-serif. fontconfig just tries to find out a best font against the
> request where may contains "Symbol" in family name. that is almost
> equivarent to find out "Cantarell" as a desktop font in GNOME. If not,
> trying to pick something up by other conditions then.
> 
> In that sense, that could be said that we are *just* missing a "Symbol"
> font. This isn't a sort of bug.
> 
> If we are going to deal with "Symbol" without any special handling, thus, we
> just need to add a substitute config to the proper font package which has
> enough coverage or metrics compatible for "Symbol".
> To be convenient, we could add it into fontconfig but it won't fix any
> issues without real fonts. so we should find out any candidate font packages
> for that instead of doing something in fontconfig.

I was looking at how to achieve this. I couldn't get the "symbol" flag working which I supposed would help here (but would need changes in poppler when creating pattern). Other possibility seems the "prefer" element which works here for me.

Do you think that adding something like this to config files of suitable fonts wouldn't break things?:

  <alias>
    <family>Symbol</family>
    <prefer><family>DejaVu Sans</family></prefer>
  </alias>

Comment 27 Akira TAGOH 2022-10-14 13:18:09 UTC
That looks like a strong claim. "Symbol" font won't be picked up when someone has the real "Symbol" font installed. in this case, "default" would be better choice instead of "prefer".
If DejaVu Sans is better substitute font for Symbol, that should works then.

Comment 28 Akira TAGOH 2023-02-07 05:55:32 UTC
BTW does google-noto-sans-symbols-fonts and/or google-noto-sans-symbols2-fonts help?
If not, how about gdouros-symbola-fonts?

Comment 29 rgb 2023-02-07 14:30:44 UTC
Doesn't work with any or all of these three installed, sorry.  So far, the only solution I've found that consistently works is embedding fonts with e.g.

  ps2pdf -dPDFSETTINGS=/printer solutions-for-week.ps

so that's in all of my work Makefiles.  It is still a problem, though, that hasn't gone away.

Comment 30 Akira TAGOH 2023-02-08 09:44:10 UTC
Sorry, my words weren't enough. Well, you may need to write a config like the above but replace DejaVu Sans to any of them. Unfortunately just installing them doesn't help right. I'm asking what is sufficient for alternatives of Symbol font.

Please put the following config into $HOME/.config/fontconfig/conf.d/0-symbol.conf and replacing FONTNAME to any of "Noto Sans Symbols", "Noto Sans Symbols 2", "Symbola".

<fontconfig>
  <alias>
    <family>Symbol</family>
    <default><family>FONTNAME</family></default>
  </alias>
</fontconfig>

This will makes fontconfig to pick up any of them as alternatives to Symbol.

Comment 31 rgb 2023-02-08 17:55:02 UTC
Well, I read the fonts-conf documentation and examples pretty thoroughly, installed font-manager so I could see the fonts themselves, and there are many, many font sets on the system that contain the requisite characters.  It is very difficult to tell which one is causing the problem or how to replace it.  I spent two hours trying variations on your <alias> section including <match> statements, replacing the various systems fond initialization steps, etc.  It sadly remains the case that while I can display my unembedded test file on a scientific linux box in the department and it renders perfectly (over X) when I try to look at exactly the same file on Fedora it has nothing but boxes.  My embedded font ps2pdf version of the same file displays everywhere.

I agree that it is probably something in /etc/fonts/fonts.conf and/or /etc/fonts/conf.d/[??]whatever-symbol-font-isn't-working.conf and that just the right override might fix it, that requires diffing and checking around 100+ files, most of which are certainly irrelevant, looking for a possibly significant change in an XML that I don't completely understand to see which one works correctly on scientific linux (a RH base IIRC) but not on Fedora (another RH base).  I could maybe install a Centos VM to test -- I don't have a RH license on any personal systems, obviously.

The possibility remains that it is a change in evince itself as well.  This I can't really test -- obviously, if I copy over a binary from the system where it works it has the wrong libraries on my laptop, and mucking around at the library level is an open invitation to having to do a hard reinstall (been there, done that:-).

Right now I HAVE to go back to my regular work and write a quiz for my physics students with (sigh) embedded fonts and so far I nothing I've done has fundamentally broken font rendering per se, but in any event no, the alias above does not work whether or not it is font.conf or 0-symbol.conf.  The documentation suggests that the former is the right place for it -- and I could verify that this file was indeed being parsed in real time as I made changes as errors were instantly reported in tty's containing rendered fonts -- but the latter seems like it might only be scanned at boot or login time, since the leading 00 (if I understand things) represents the order in which the file configs are layered at startup.  I >>think<< the system rereads this ever 30 seconds by default so it shouldn't matter, but again -- no time to test, an incredibly complex system and syntax, and crappy tools for manipulating it or even displaying it.  Font-manager is the best I've found, but I don't know if it can be used to rewrite rules yet (or if it is wise to trust it while doing so).

Sorry.

Comment 32 Ben Cotton 2023-04-25 17:58:32 UTC
This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 33 Jens Petersen 2023-05-15 10:31:51 UTC
I can reproduce in F38 and Rawhide:

⬢ toolbox39$ fc-match -s Symbol
StandardSymbolsPS.t1: "Standard Symbols PS" "Regular"
NotoSans[wght].ttf: "Noto Sans" "Regular"
NotoSansSymbols-Regular.ttf: "Noto Sans Symbols" "Regular"
NotoSansSymbols2-Regular.ttf: "Noto Sans Symbols 2" "Regular"
NimbusSans-Regular.otf: "Nimbus Sans" "Regular"
NotoSansMono[wght].ttf: "Noto Sans Mono" "Regular"
NotoSansCJK-VF.ttc: "Noto Sans CJK JP" "Regular"
D050000L.otf: "D050000L" "Regular"
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Regular"
DejaVuSansMono-Bold.ttf: "DejaVu Sans Mono" "Bold"
NotoColorEmoji.ttf: "Noto Color Emoji" "Regular"

After installing Bitstream Vera:

$ fc-match -s Symbol
StandardSymbolsPS.t1: "Standard Symbols PS" "Regular"
Vera.ttf: "Bitstream Vera Sans" "Regular"
NotoSansSymbols-Regular.ttf: "Noto Sans Symbols" "Regular"
NotoSansSymbols2-Regular.ttf: "Noto Sans Symbols 2" "Regular"
NotoSans[wght].ttf: "Noto Sans" "Regular"
NimbusSans-Regular.otf: "Nimbus Sans" "Regular"
NotoSansMono[wght].ttf: "Noto Sans Mono" "Regular"
NotoSansCJK-VF.ttc: "Noto Sans CJK JP" "Regular"
D050000L.otf: "D050000L" "Regular"
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Regular"
DejaVuSansMono-Bold.ttf: "DejaVu Sans Mono" "Bold"
NotoColorEmoji.ttf: "Noto Color Emoji" "Regular"

Comment 34 pstils 2024-03-18 10:05:33 UTC
Following-up on a thread in the R-Sig-Fedora mailing list where the same bug was discussed. I initially posted in bug 2088665 "Noto Sans is chosen to display symbol characters it doesn't contain", which I think probably is the same underlying issue, but the bug title here is probably more pertinent, as was pointed out to me.

As has been suggested above, the work-around is to make a .fonts.conf file in ~/ 

The following substitution is working nicely for me: 

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>

  <match target="pattern">
    <test name="family" qual="any" >
      <string>Symbol</string>
    </test>
    <edit name="family" mode="assign" binding="same">
      <string>OpenSymbol</string>
    </edit>
  </match>

</fontconfig>


The OpenSymbol font comes from libreoffice-opensymbol-fonts if you need to install it, though you'll probably have it already as it comes with Libre Office (though I've heard that RHEL will / has stopped shipping with Libre Office? I also don't know whether e.g., a flat-packed libre office would make such fonts available for system-wide use). Nonetheless, if you don't have OpenSymbol for whatever reason, installing it is straight-forward.


Note You need to log in before you can comment on or make changes to this bug.