Histogram chart doesn't get translated into html properly

[rambunctiousapple]

The histogram output from @benchmark looks like this in the REPL

But displays like this in the html generated by Publish.jl

The fact that it's not in color is a bummer but the histogram bars are not rendered properly, which is a more serious issue.

I'm willing to help fix these issues I'm posting if you could point me to the parts of the code where the error is likely to be occurring and give me a little guidance about how to proceed.

[MichaelHatherly]

histogram bars are not rendered properly

Probably a font issue. Can you check what font your browser is selecting for that text?

The fact that it's not in color is a bummer

Hooking into https://juliadocs.github.io/ANSIColoredPrinters.jl/dev/ in someway to get the colors is probably the most straightforward way of getting that working, would be a nice to have feature, definitely.

[rambunctiousapple]

I've poked around using dev tools for the browser but I'm not a css/html guru. Not sure where to find the font information for the particular block that has the histogram. I'll poke around more this weekend.

[rambunctiousapple]

I believe this is the font for the histogram text. Is this correct?

code {
    font-family: "Source Code Pro", Consolas, "Ubuntu Mono", Menlo, "DejaVu Sans Mono", monospace, monospace !important;
    font-size: 0.875em;
}

[rambunctiousapple]

I'll take a crack at getting color working. Where should I look in the publish.jl code to figure out how to add the functionality of ANSIColoredPrinters?

[MichaelHatherly]

Printing to terminal happens around here: https://github.com/MichaelHatherly/Publish.jl/blob/37bba4180c28f7bb80de40667adf938b15956812/src/cells.jl#L73= if I recall correctly.

Font choices for HTML/CSS happen here:
https://github.com/MichaelHatherly/Publish.jl/blob/37bba4180c28f7bb80de40667adf938b15956812/_themes/default/publish.css#L29=, perhaps adjusting those will give a better alignment for those boxdrawing characters in the histogram.

[rambunctiousapple]

I didn't have the Source Code Pro font installed. Once I installed it the plot came out better but still not entirely correct. The heights and horizontal spacing seem correct, but there are blank spaces in some of the bars where there shouldn't be.

I also changed this line

Publish.jl/_themes/default/publish.css

Line 29 in 37bba41

font-family: "Source Code Pro", Consolas, "Ubuntu Mono", Menlo, "DejaVu Sans Mono", monospace, monospace !important;

to remove Source Code Pro and instead use JuliaMono, which I do have installed, and got the same output.

This seems very fragile though if it depends on the particular font installed on my machine, or on the github servers. Does the Julia distribution come with a default monospaced font, with the appropriate glyphs for these bar graphs, which is used in the REPL?

Perhaps the default REPL font should be the default font for the code{...} specification here

Publish.jl/_themes/default/publish.css

Line 29 in 37bba41

font-family: "Source Code Pro", Consolas, "Ubuntu Mono", Menlo, "DejaVu Sans Mono", monospace, monospace !important;

In that case these plots would always come out correct whether being rendered on my local machine or on the github servers.

Do you know what the default REPL font is? I don't and also don't know how to find out what it is.

[rambunctiousapple]

I'll take a look at color printing now and see if I can get that working.

[MichaelHatherly]

Does the Julia distribution come with a default monospaced font, with the appropriate glyphs for these bar graphs, which is used in the REPL?

Do you know what the default REPL font is? I don't and also don't know how to find out what it is.

There isn't. Julia does not come bundled with a font, whatever font is used in their terminal program will be what is used. Font selection isn't something that a programming language can really pick for the user unfortunately.

Probably a more robust route to take would be to bundle (or just reference via webfonts) the JuliaMono font since that covers quite a bit of the character range. There's always going to be some form of edge case when we're dealing with fonts and webbrowsers though.

[rambunctiousapple]

@cormullion has a JuliaMono webfonts directory and .css files set up already so it shouldn't be too difficult to set JuliaMono as the default REPL webfont for Publish.jl.

Bundling the fonts would be less fragile, if @cormullion has no objections. But then there is the issue of keeping the Publish.jl copy of JuliaMono up to date with the original. Looks like there were changes to the JuliaMono repo in Feb. 2022, so it is still under active development. Maybe at every new release of Publish.jl the latest version of JuliaMono could be downloaded?

Using a webfont reference has the issue that if the JuliaMono repo is unavailable for whatever reason then pages may not render properly. The problems with rendering are edge cases anyway, mainly going to show up when people are doing console plotting. So maybe not such a severe problem. And webfonts would be simpler than bundling.

@MichaelHatherly which do you think is preferable, bundling or webfonts? I can take a crack at a PR once you make a decision.

[MichaelHatherly]

And webfonts would be simpler than bundling.

Let's go with the simpler option of webfonts for now. It can be revisited should it actually cause issues in use.

[cormullion]

Most Julia Documenter-built docs (since 0.27.something) get their fonts served by cdnjs.cloudfare; Pluto notebooks are served by cdn.jsdelivr; both are pretty central to the web, so outages should be rare either way.

Development on the JuliaMono font has slowed down, now. Perhaps a few releases per year to fix bugs, rather than 30-40!

Thanks for using/considering JuliaMono!

[rambunctiousapple]

@MichaelHatherly I looked here https://cdnjs.com/libraries/juliamono and found many different versions of JuliaMono, up to 44 now.

When creating the webfont url font-face definition is the normal practice to embed the full path to the font, like this:

@font-face {
    font-family: JuliaMono;
    font-weight: 300;
    font-style: normal;
    src: url("https://cdnjs.cloudflare.com/ajax/libs/juliamono/0.044/JuliaMono-Light.woff2)" format("woff2");
    text-rendering: optimizeLegibility;
}

hardcoding the version number? Or is there some way to make this automatically use the latest version?

If the version number must be hardcoded that would need to be manually updated when making new versions of Publish.jl, which could be error prone. Or the Publish.jl build process could somehow figure out the latest version of JuliaMono and update the version number in the theme file publish.css automatically.

Is there some way to have the prefix https://cdnjs.cloudflare.com/ajax/libs/juliamono/0.044/ stored just once in the css file and then automatically prefixed to the font urls?

[rambunctiousapple]

Most Julia Documenter-built docs (since 0.27.something) get their fonts served by cdnjs.cloudfare; Pluto notebooks are served by cdn.jsdelivr; both are pretty central to the web, so outages should be rare either way.

Development on the JuliaMono font has slowed down, now. Perhaps a few releases per year to fix bugs, rather than 30-40!

Thanks for using/considering JuliaMono!

@cormullion when Documenter.jl references webfonts does it use harcoded url's like this:

@font-face {
    font-family: JuliaMono;
    font-weight: 300;
    font-style: normal;
    src: url("https://cdnjs.cloudflare.com/ajax/libs/juliamono/0.044/JuliaMono-Light.woff2)" format("woff2");
    text-rendering: optimizeLegibility;
}

or is there some more generic way to do this that gets just the latest version of the font?

I'm a css/html newbie and have never used webfonts before so apologize in advance if this is well known stuff.

[cormullion]

Documenter uses this at the moment. People generally are happy to manually update the version when they feel ready, rather than always getting the latest version...

I think you needn't worry about versions of the font too much now (unless reporting bugs and errors); the differences between releases are mostly matters of changes of a few thousandths of an inch or the addition of some obscure Unicode characters.