Using -dshow-available-fonts with LilyPond v2.25.12 throws error with non–UTF-8 encoded font info

2024-01-07 Thread Nate Whetsell
Hi there, At commit c3f2dddaa2b16231bc2f786fba7421f03f7da7af , All_font_metrics::display_fonts was changed

Re: Using -dshow-available-fonts with LilyPond v2.25.12 throws error with non–UTF-8 encoded font info

2024-01-08 Thread Werner LEMBERG
> On macOS Ventura v13.6.3 (and almost certainly other versions), the > string produced when using -dshow-available-fonts need not be > encoded as UTF-8. Thanks, should be fixed with this MR: https://gitlab.com/lilypond/lilypond/-/merge_requests/2231 Out of interest: Which font shows this be

Re: Using -dshow-available-fonts with LilyPond v2.25.12 throws error with non–UTF-8 encoded font info

2024-01-09 Thread Nate Whetsell
Thanks for making the merge request. Unfortunately, it didn’t fix the issue, although it really seems like it should have. I’m starting to think this may be a bug in Guile. With the patch applied, running `lilypond -dshow-available-fonts` outputs: GNU LilyPond 2.25.12 (running Guile 3.0) ERROR:

Re: Using -dshow-available-fonts with LilyPond v2.25.12 throws error with non–UTF-8 encoded font info

2024-01-11 Thread Werner LEMBERG
> Thanks for making the merge request. Unfortunately, it didn’t fix > the issue, although it really seems like it should have. Thanks for the testing it and the detailed analysis. I've changed the status of the Merge Request to 'draft'. > I’m starting to think this may be a bug in Guile. Can y

Re: Using -dshow-available-fonts with LilyPond v2.25.12 throws error with non–UTF-8 encoded font info

2024-01-12 Thread Nate Whetsell
> Can you make your example code generic and report it to the Guile people? Done. > How shall we proceed? Because this issue occurs with a macOS system font, it it likely to impact most (possibly all) LilyPond users on macOS. Consequently, it may be necessary to revert commit c3f2dddaa2b1623

Re: Using -dshow-available-fonts with LilyPond v2.25.12 throws error with non–UTF-8 encoded font info

2024-01-13 Thread Jean Abou Samra
Le mardi 09 janvier 2024 à 12:43 -0500, Nate Whetsell a écrit : > I’m starting to think this may be a bug in Guile. Well, Guile's encoding handling is quite bug-ridden. signature.asc Description: This is a digitally signed message part

Re: Using -dshow-available-fonts with LilyPond v2.25.12 throws error with non–UTF-8 encoded font info

2024-01-13 Thread Jean Abou Samra
Le vendredi 12 janvier 2024 à 06:08 +, Werner LEMBERG a écrit : > How shall we proceed? I don't have the time to check this but is there not a way to simply write bytes to (current-error-port) in Guile? IIRC, all Guile ports can be used in both binary and text ways. Also, I'm pretty sure that

Re: Using -dshow-available-fonts with LilyPond v2.25.12 throws error with non–UTF-8 encoded font info

2024-01-13 Thread Jean Abou Samra
> I don't have the time to check this but is there not a way to simply write > bytes to (current-error-port) in Guile? Like scm_c_write < https://www.gnu.org/software/guile/manual/html_node/Using-Ports-from-C.html > ? signature.asc Description: This is a digitally signed message part

Re: Using -dshow-available-fonts with LilyPond v2.25.12 throws error with non–UTF-8 encoded font info

2024-01-13 Thread Nate Whetsell
I can confirm that replacing scm_write_line (ly_string2scm (str), port); with scm_c_write (port, str.c_str (), str.length ()); fixes the issue on my end. I’d be happy to make a merge request for this. > On Jan 13, 2024, at 6:19 PM, Jean Abou Samra wrote: > >> I don't have the time to check t

Re: Using -dshow-available-fonts with LilyPond v2.25.12 throws error with non–UTF-8 encoded font info

2024-01-14 Thread Werner LEMBERG
> I can confirm that replacing > > scm_write_line (ly_string2scm (str), port); > > with > > scm_c_write (port, str.c_str (), str.length ()); > > fixes the issue on my end. I’d be happy to make a merge request for > this. I've updated https://gitlab.com/lilypond/lilypond/-/merge_requests/2231

Re: Using -dshow-available-fonts with LilyPond v2.25.12 throws error with non–UTF-8 encoded font info

2024-01-14 Thread Werner LEMBERG
> Also, I'm pretty sure that the intent of FcChar8* in Fontconfig is > to represent UTF-8 so this is probably worthy of a bug report to the > Fontconfig people? Indeed. To do so it would be helpful to check the output of `fc-list` (ideally with proper patterns to make the result more similar to