Skip to main content

Custom Fonts - Cyrillic

Davide Riva

Hello,

I uploaded my custom font and is rendering fine unless the text is cyrillic.
The font support russian unicode-range cause we use the same set on our emails, but not on cloudinary transformation. Any help?

0

Comments

7 comments

Date Votes
  • Aleksandar Kostadinov

    Hi Davide,

    Cloudinary also supports Unicode characters in text overlays, although they would need to be URL encoded. In order to investigate the issue you are seeing with the text overlay, may I please ask you to share a URL where you are using the custom font and specifying some Cyrillic text which isn't rendering correctly?

    Best regards,

    Aleksandar

    0
  • Davide Riva

    Hello Aleksandar,

    here is a test:

    https://a.suitsupplycdn.com/image/upload/w_960/w_880,c_fit,l_text:email:common:fonts:gt-america-standard-light.ttf_39_regular_center_letter_spacing_0_line_spacing_21:Lorem%20a%20ipsum%20dolor%20sit%20amet%202980%D0%A0%D0%A3%D0%91%252E,co_rgb:2D2E2C,fl_text_no_trim/g_center,x_0,y_0,fl_layer_apply,q_auto,f_auto,fl_progressive/v1/email/2020/test-sam/test.jpg

    Has you can see the string РУБ is not displayed properly.

    Thanks

    0
  • Aleksandar Kostadinov
    Edited

    Hi Davide,

    Thanks for sharing this.

    I tried to access the link and can see that these characters aren't rendering on the text overlay. I then downloaded the font file and ran it through https://fontdrop.info which reads TTF/OTF files and extracts some information such as version, copyright information and in addition, all supported characters/glyphs. Based on the output from that it seems that this font does not support these Unicode character endpoints.

    For example, if I use a different Unicode character that is in the list of supported ones, such as Æ, then it renders as expected.

    https://a.suitsupplycdn.com/image/upload/w_960/w_880,c_fit,l_text:email:common:fonts:gt-america-standard-light.ttf_39_regular_center_letter_spacing_0_line_spacing_21:Lorem%20a%20ipsum%20dolor%20sit%20amet%202980%C3%86%252E,co_rgb:2D2E2C,fl_text_no_trim/g_center,x_0,y_0,fl_layer_apply,q_auto,f_auto,fl_progressive/v1/email/2020/test-sam/test.jpg

    Using any Google font, such as Roboto which supports these characters also allows them to be rendered.

    https://res.cloudinary.com/demo/image/upload/l_text:Roboto_60:%D0%A0%D0%A3%D0%91,co_white/sample.jpg

    Looking at the font you're using in more details - https://www.grillitype.com/shops/gt-america - it seems there are different variations such as compressed, standard, extended and expanded. Do you know whether there are differences between the character sets supported in each or do these variations refer to something else?

    I've also attached a link to the Roboto-Regular.ttf which you can run through FontDrop to see the Cyrillic characters explicitly listed under the supported glyphs.

    https://res.cloudinary.com/demo/raw/upload/Roboto-Regular_lscvvk.ttf

    Do you use any other fonts we can run through FontDrop to see the output and then test with them regarding the support of the Cyrillic characters?

    Best regards,

    Aleksandar

    1
  • Davide Riva

    Hello Aleksandar,

    thanks a lot for your investigation.

    I did some tests on my side as well and yes, the set is not supporting the cyrillic.

    0
  • Milan Simonović
    Edited

    Hi Aleksander,

    a related question regarding custom fonts, i'm getting Content-type "application/octet-stream" instead of "application/x-font-ttf":

    ```

    $ curl --head https://res.cloudinary.com/demo/raw/upload/v1582222947/Roboto-Regular_lscvvk.ttf | grep Content

    Content-Length: 171272
    Content-Disposition: attachment; filename="Roboto-Regular_lscvvk.ttf"
    Content-Type: application/octet-stream
    ```

    The same happens when with raw resources uploaded with "type: 'authenticated" as per this update.

    Is there a way to have CDN respond with the correct font mime type?

    ```

        ".afm"            : "application/x-font-type1",
        ".bdf"            : "application/x-font-bdf",
        ".eot"            : "application/vnd.ms-fontobject",
        ".gsf"            : "application/x-font-ghostscript",
        ".otf"            : "application/x-font-otf",
        ".pcf"            : "application/x-font-pcf",
        ".pfa"            : "application/x-font-type1",
        ".pfb"            : "application/x-font-type1",
        ".pfm"            : "application/x-font-type1",
        ".pfr"            : "application/font-tdpfr",
        ".psf"            : "application/x-font-linux-psf",
        ".snf"            : "application/x-font-snf",
        ".ttc"            : "application/x-font-ttf",
        ".ttf"            : "application/x-font-ttf",
        ".woff"            : "font/woff",
        ".woff2"        : "font/woff2"

    ```

    best,
    Milan

    0
  • Aleksandar Kostadinov

    Hi Milan,

    This actually came up recently and there is an internal ticket for us to update the MIME Type returned - specifically for OTF, TTF, WOFF and WOFF2 at first. I'll link this thread to the internal ticket and I can confirm once there are updates in regards to this change.

    1
  • Aleksandar Kostadinov

    Hi @Milan,

    I wanted to update this thread to confirm that the changes relating to MIME Type of font files have been released. Font files (ttf, otf, woff, woff2) uploaded from now will be stored and delivered with that `font/X` MIME Type rather than `application/octet-stream`.

    You could test this out first by uploading a new font file in your cloud and then checking the response headers when accessing it via the delivery URL.

    To ensure the Content-Type is updated on all your existing/already uploaded fonts, you will want to perform either of the following:

    1. Download your existing font file locally, delete the existing font file from Cloudinary (with CDN invalidation by passing 'invalidate' => true in your upload() API call) and finally, immediately upload the same file with the same public_id so that your existing URLs will continue to work but deliver the new file which will have the updated headers.
    2. Upload the font with a new public_id and use the new URL (with new public_id) on your side instead of the existing one.
    0

Post is closed for comments.

Didn't find what you were looking for?

New post