Font handling in Gtk on MacOS is weird: Pango only calculates the layout for computing box sizes. The actual glyph selection and layout is handled by Cairo, and I don't think it knows how to use CoreText's font substitution. WebKitGtk complicates matters by requiring the FreeType2 Pango backend as well and that does its own font substitution. Regardless, pango is finding the emojis so the test passes. Cairo isn't putting a missing glyph glyph there like I'd expect. I haven't yet figured out why not.
I can think of two avenues to try: Simply forcing have_glyphs to false on MacOS would display the regular letters. Not as pretty but it's sure to work. A bit more difficult and in need of testing would be to use CSS to set the font family for the Association cell to Apple Color Emojis on MacOS. Regards, John Ralls > On Jun 24, 2020, at 3:53 PM, Adrien Monteleone > <adrien.montele...@lusfiber.net> wrote: > > Sorry, I forgot to report back that after looking over the entire unicode > table, I can’t find anything suitable as replacement glyphs. (at least not > without a specialized typeface, which GnuCash would have to package) > > So on Mac at least, we lose the ability to see there is an attachment or > location association. > > Regards, > Adrien > >> On Jun 24, 2020 w26d176, at 12:03 PM, Adrien Monteleone >> <adrien.montele...@lusfiber.net> wrote: >> >> I tried pasting them into a Notes field, they take up space, but do not >> display. >> >> I fired up the GTKInspector to see if I could find a clue —no dice. CSS has >> no effect, and it is near impossible to target anything besides the register >> sheet as a whole, or the entry field. (and one can’t edit the attachment >> cell to focus it) I even tried changing the font to Apple Color Emoji and it >> still didn’t display. >> >> So this might be a GTK-Mac emoji issue. (I can’t paste any emojis in, same >> result) Or if others on Mac can use and see emoji, then something is wrong >> with my setup. >> >> But this failure to display also means the fall-back can’t be seen. GnuCash >> thinks it doesn’t need to fall-back, and puts the glyph there, but it shows >> up as simply a space and is invisible. >> >> Regards, >> Adrien >> >> >>> On Jun 24, 2020 w26d176, at 10:57 AM, Robert Fewell <14ubo...@gmail.com> >>> wrote: >>> >>> I tested this on a couple of Linux boxes and also on Windows and had no >>> trouble so maybe it is a Mac issue. Unfortunately I do not presently have >>> one so I do not know, maybe John might have an idea, the only ideas I have >>> is to set different code points for a paperclip and links for Mac's, >>> disable it for Macs or maybe change the test. >>> >>> Adrien do you have likely candidates for those? >>> >>> On Wed, 24 Jun 2020 at 16:28, Adrien Monteleone >>> <adrien.montele...@lusfiber.net> wrote: >>> Those glyphs only show up for me in Character Viewer as ‘Apple Color >>> Emoji’. (thus not part of any regular typeface) Not sure how to get that >>> included in GnuCash if it isn’t there by default. Certainly, I don’t want >>> to change my default font to all emojis. >>> >>> But that doesn’t explain the lack of fall back ‘f’ and ‘w’. >>> >>> I had a custom CSS file for colors and font sizes, so I pulled that and >>> still the fall backs are not there. >>> >>> Regards, >>> Adrien >>> >>>> On Jun 24, 2020 w26d176, at 7:38 AM, Robert Fewell <14ubo...@gmail.com> >>>> wrote: >>>> >>>> Adrien, >>>> That is a bot surprising, there is a test for the glyphs in the font and >>>> if not present should default to 'f' and 'w', code points are.. >>>> #define GLYPH_PAPERCLIP "\360\237\223\216" // Codepoint U+1F4CE >>>> #define GLYPH_LINK "\360\237\224\227" // Codepoint U+1F517 >>>> >>>> >>>> Regards, >>>> Bob >> > > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
