Load webfont in paginated view

[typometre]

Hi How are we suppose to load webfonts.

In the css file, I have @font-face rule

@font-face { font-family: 'Ink';
 src: url('./webfonts/InknutAntiqua-Regular.eot'), /*IE9CompatibilityModes*/ 
 url('./webfonts/InknutAntiqua-Regular.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */ 
 url('./webfonts/InknutAntiqua-Regular.woff') format('woff'), /* Navigateurs modernes */
 url('./webfonts/InknutAntiqua-Regular.ttf') format('truetype'); /* Safari, Android, iOS */
 }

It works in the markdown preview but failed in the pagejs preview.

I saw #5 and I think the issue is similar. The <base href=""> is set as I can see it in developper tools but the font doesn't load as panwriter seems to look for them from the folder of the app and not from the document folder. It is trying to load it from file:///Applications/PanWriter.app/Contents/Resources/app.asar/static/webfonts/InknutAntiqua-Regular.ttf

Best regards. And thanks for Panwriter and your help.

[mb21]

Thanks for the bug report. Indeed, that doesn't work in the paginated view. Probably paged.js is not taking the <base> tag into account... I'll take a look.

[mb21]

Indeed, I filed an upstream issue with paged.js.

[typometre]

Thanks @mb21 Hope we would find a way. I didn't got the problem loading fonts with pagedjs using their grunt compile process. But I found panwriter really nice, simpler and like the idea of direct markdown source to pagedjs without having to deal with server, terminal or compilation.

[mb21]

PanWriter needs to use the <base> tag (which you wouldn't normally need), because the current directory is where the app is located, not where the opened document is located.

But until the upstream bug is fixed, you can either:

• install the font system-wide, or
• move your CSS and the font file to the PanWriter user data directory. See https://github.com/mb21/panwriter#user-data-directory (note that I just fixed this, so you'll have to update to the newest release).

It's great to hear that you like PanWriter. Let me know how it goes. Currently, I'm imagining most people will start writing some CSS in the document's style field and then later, when the amount of CSS grows and won't change as much anymore, they'll move it to a document-type file in the user data directory, where it can also be reused between document. Does that align with your use-case, or..?

[typometre]

Thanks, It's working with the update. I already use the data directory with a custom type as I got too much synthax error with CSS in the style YAML field. The document is heavy on CSS and the need of specific indentation is a big hassle. It's a test but I will have to separate CSS meant to be in the type template and CSS specific to the document.

[mb21]

Great! I've been thinking of adding a browser-developer-tools kind of GUI to edit the style metadata field.

Meanwhile, there are various ways to do multiline strings in YAML. For example quote the whole string, then you don't need to worry about indentation:

---
style: "
h1 {
  font-family: 'Courier New'
}
"
---

[typometre]

Thanks for the trick. I diddn't knew this. This definitly surely make it much easier and much more usable. GUI would be a nice improvment.