Font Consolas

[juanfal]

I have specified the font I usually use, Consola, in my preferences (Default.sublime-keymap):

  ,{
        "keys": ["ctrl+alt+n"],
        "command": "export_html",
        "args": {
            "table_mode": false,
            "numbers": false,
            "wrap": 0,
            "multi_select": true,
            "color_scheme": "Packages/Color Scheme - Default/Monokai Bright.tmTheme",
            "alternate_font_face": "Ubuntu Mono",
            "style_gutter": false,
            "no_header": true,
            "save_location": "/private/tmp",
            "time_stamp": ""
        }
    }

but it always export in Courier… could it be possible to pick an HTML/other available font instead of Courier…? what are available?

[facelessuser]

alternate_font_face should be defined as a global settings within Export HTML settings file, not a per rule setting.

ExportHTML first grabs whatever font Sublime is globally set to use, then looks at the ExportHTML global settings to see if there is an override (or alternate) font to use instead. Then it defines the HTML CSS such that the specified font is listed first, with fallbacks to Courier and then Monospace in case any of the fonts are not found on the system when displaying the HTML.

[facelessuser]

Just for clarification, the intent was always just to display, as close as possible, text as shown in Sublime. So we first just see what font Sublime is using. The reality though is if you share your HTML output with people, they may not have the same font, so we had a simple, global override (not rule-specific) option to specify a more web-safe font.

So, just run the ExportHTML: Settings command and it will bring up the settings, you'll see how alternate_font_face is defined globally. Copy it over to your user settings and it should work assuming the browser can find the font.

[juanfal]

But I have it in both places. <img width="368" height="173" alt="Image" src="https://github.com/user-attachments/assets/cfba0875-6d63-4b5c-b78c-fb41eddf8bab" /> Default (OSX).sublime-keymap <img width="383" height="242" alt="Image" src="https://github.com/user-attachments/assets/b881ffac-9b9b-44fc-b1c3-f68cc37bf85f" /> I understand it is the case in which it can be found by the browser. So only web-safe fonts are used for the html-format, is it?

…

El 1 oct 2025, a las 14:23, Isaac Muse ***@***.***> escribió: facelessuser left a comment (facelessuser/ExportHtml#98) <#98 (comment)> Just for clarification, the intent was always just to display, as close as possible, text as shown in Sublime. So we first just see what font Sublime is using. The reality though is if you share your HTML output with people, they may not have the same font, so we had a simple, global override (not rule-specific) option to specify a more web-safe font. So, just run the ExportHTML: Settings command and it will bring up the settings, you'll see how alternate_font_face is defined globally. Copy it over to your user settings and it should work assuming the browser can find the font. — Reply to this email directly, view it on GitHub <#98 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG2U3FVLDO6SJWELRQMC4D3VPBTFAVCNFSM6AAAAACH7IURAKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNJWGA3DGMBTG4>. You are receiving this because you authored the thread.

[facelessuser]

I understand it is the case in which it can be found by the browser. So only web-safe fonts are used for the html-format, is it?

No, only fonts your browser can find. If your computer has the font you specify, then it'll be okay. If you give it to someone who doesn't have that font, it'll show one of the fallback fonts.

Font's in the output are controlled with basic CSS. It's really that simple.

.code_page {
    background-color: {{ var.page_bg }};
    font-family: {{ var.font_face }}, "Courier", Monospace;
    font-size: {{ var.font_size }}pt;
    tab-size: {{var.tab_size}};
}

Whatever is specified for font_face in Preferences.sublime-settings or in alternate_font_face in ExportHTML.sublime-settings will be what is inserted in CSS. Then it is the browsers job to properly display the font.

ExportHTML does nothing else with fonts. It just specifies it in the CSS. If that is not working, you need to figure out how to specify the name such that the browser sees it.

Now, let's be clear here, one of your examples shows you passing alternate_font_face into a command via args. That is not currently supported.

I know nothing of your setup, but if you can get your font name working in this online example: https://codepen.io/facelessuser/pen/zxrKYog via CSS. It should work in ExportHTML if you specify the name the same way. If you discover that what you specify in the settings does not make it to the CSS properly, then we can look at fixing that, but I have no indication from you that we are looking at that kind of an issue.

[facelessuser]

I will also note that maybe we could allow in the future ways to inject things like:

<link href='https://fonts.googleapis.com/css?family=Ubuntu+Mono' rel='stylesheet'>

So that a user could link to a font and then specify it for systems that may not have it by default.

[juanfal]

The only way I have found to avoid Safari's aversion to rendering local fonts is this:

 <link href="https://fonts.googleapis.com/css2?family=Ubuntu+Mono&display=swap" rel="stylesheet">

With Firefox, you don't need anything: it renders font-family: ‘Ubuntu Mono’, Monospace; without any problems. But even with FF, if you copy the rendered page into KeyNote, KeyNote changes the font to Courier. Safari isn't even able to render it directly in Ubuntu Mono... always monospace: Courier, rendering and copying. Of course. Security measures.

But with that link to the external font in the header, everything works: Rendering in Safari and copying/pasting the rendered text into KeyNote with the correct font!

[facelessuser]

Yes, that's because that additional HTML forces the font to get downloaded.

I can't control what fonts are installed on your machine. I also can't control how an application accesses fonts either. We are currently appreciating fonts exactly how we are supposed for browser where the font is already installed and accessible.

ExportHTML was designed simply for the browser on a machine where the font is already installed. I can't help if FF has some special mitigation to grab fonts that aren't installed or if Safari doesn't.

I can consider adding a feature where you let a user define some HTML/CSS fragment to inject to ensure a font is acquired. Until then, you'd have to manually inject something as you did in your experiments.

I would not consider this a bug in our implementation, but it's possible we can provide a little more flexibility to help users acquire fonts in situations where it cannot be found.