OSX: Bad kerning in disk image background #16836

1. 
   dongcarl commented at 6:08 pm on September 9, 2019: member

   The background image generated by make deploy for our OSX disk image has bad kerning at least for the OSX version I tested.

   

   Software specs:

   0ProductName:    Mac OS X
   1ProductVersion: 10.14.6
   2BuildVersion:   18G87
   

2. dongcarl added the label Bug on Sep 9, 2019
3. dongcarl added the label macOS on Sep 9, 2019
4. dongcarl added the label Build system on Sep 9, 2019
5. dongcarl added the label good first issue on Sep 9, 2019
6. 
   MarcoFalke commented at 12:07 pm on September 10, 2019: member

   Is this with gitian or a native build?
7. 
   dongcarl commented at 12:12 pm on September 10, 2019: member

   Is this with gitian or a native build?

   Native build, perhaps we don’t care that much about the disk image for native builds?

8. 
   fanquake commented at 5:33 am on September 11, 2019: member

   @dongcarl Do you have any more info? I have never seen this issue locally.
9. 
   jonasschnelli commented at 1:26 pm on September 12, 2019: contributor

   The background.svg image uses a font called Tuffy (I don’t know why). This is probably suboptimal.

   I guess @dongcarl’s rsvg-convert has issues with either the font or with the general bitmapification of text.

   What happens if you convert manually? rsvg-convert contrib/macdeploy/background.svg -f png -d 36 -p 36 -o test.png

10. 
    dongcarl commented at 4:22 pm on September 12, 2019: member

    @jonasschnelli Yes the kerning problem persists when I convert manually… Looking at Font Book on my system there doesn’t seem to be a font named “Tuffy”, which is probably the problem. Perhaps we could switch to something else?
11. 
    dongcarl commented at 6:55 pm on September 12, 2019: member

    It would seem that this is not due to missing fonts but rather a regression in rsvg-convert as @jonasschnelli and I discovered. This regression was introduced somewhere between rsvg-convert 2.40.16 and 2.46.0.
12. 
    jonasschnelli commented at 7:03 pm on September 12, 2019: contributor

    Looks like its related to the width="1000pt" height="640pt" part in the <svg> tag (changing from pt to px makes the kerning looks good, but unsure about the output image size).
13. 
    jonasschnelli commented at 7:36 am on September 13, 2019: contributor

    Looks like the @2x image is fine (retina/HiDPI). Can you confirm @dongcarl ?
14. 
    za-kk commented at 9:19 am on September 21, 2019: contributor

    Looks like the @2x image is fine (retina/HiDPI). Can you confirm @dongcarl ?

    Tested this issue using a retina display Macbook Pro running the same software specs, no kerning on my side which suggests the @2x image works as intended.

    I also get the kerning if i convert manually using rsvg-convert contrib/macdeploy/background.svg -f png -d 36 -p 36 -o test.png

    but not if i convert @2x manually using rsvg-convert contrib/macdeploy/background.svg -f png -d 72 -p 72 -o test.png

    Software specs:

    0ProductName:    macOS Mojave
    1ProductVersion: 10.14.6
    2BuildVersion:   18G87
    

15. 
    za-kk commented at 10:28 pm on September 21, 2019: contributor

    Looks like its related to the width="1000pt" height="640pt" part in the <svg> tag (changing from pt to px makes the kerning looks good, but unsure about the output image size). @jonasschnelli I’ve been playing around with this issue and as you mentioned changing from pt to px seems to solve the kerning issue.

    However when using px instead of pt, the png outputs from the rsvg-convert seem to create the exact same file (regardless of the change in dpi) and therefor having the two different image output files (background.tiff.png and background.tiff@2x.png) would be pointless.

    A potential solution would be to have two different background.svg files for each image resolution, however a solution that keeps it confined to one background.svg would seem more appropriate.

    I’m willing to take on fixing this issue if nobody else already has, not sure of the best solution yet and your thoughts on this would be appreciated.

    Also I’m fairly new around here so apologies if i haven’t followed correct procedure or have put this in the wrong place (working my way through the contributing guide)

16. 
    dongcarl commented at 8:47 pm on October 15, 2019: member

    I’ve looked into this issue some more and provided upstream with a minimal reproducer: https://gitlab.gnome.org/GNOME/librsvg/issues/520

    It appears to be an issue that only occurs on OSX.

17. 
    dongcarl commented at 7:40 pm on October 18, 2019: member

    Small update: seems to be a pango issue https://gitlab.gnome.org/GNOME/pango/issues/422
18. 
    fanquake commented at 6:25 am on August 14, 2020: member

    I’ve removed “Good first issue” and added upstream. I don’t think fixing this a high priority.
19. fanquake removed the label good first issue on Aug 14, 2020
20. fanquake added the label Upstream on Aug 14, 2020
21. 
    hebasto commented at 11:19 pm on August 19, 2021: member

    Is this still an issue?
22. 
    fanquake commented at 1:34 pm on January 18, 2022: member

    This is no longer an issue after #23909.
23. fanquake closed this on Jan 18, 2022

    ---

24. DrahtBot locked this on Jan 18, 2023

Contributors
dongcarl MarcoFalke fanquake jonasschnelli za-kk hebasto

Labels
Bug macOS Build system Upstream