Fonts don't load properly when called by python #24
Comments
|
I think webfonts are probably the correct solution for this. Having the plugin declare the fonts used for rendering seems bad. Having it be checked in to the codebase seems worse. Maybe best way is to have a way for someone configuring the system to put the fonts they want in a deployed directory. That way they can worry about legality of their fonts and whether they own them and whatnot. |
|
I do think it's important for the package to be fully functional without requiring the installation of non-packaged dependencies (this isn't opposed to what you're saying, this is just saying that I would want the font configuration / installation step to be optional rather than a required part of setup -- e.g. the user of the module can explicitly pass font configuration as part of the documented API of the module). In the mean time the current system does use embedded FOSS fonts and the license is included so the ownership question is covered. TL;DR -- I agree it would be good to remove the need for embedded fonts in the first place. For the scope of this issue I'd like to just fix the code that exists (since we already have the fonts checked in etc etc) but I will create a second issue for that goal. |
Fonts were being loaded in a way that would only work if the script was being called from the mw2pdf root (the folder containing the embedded fonts). This adds some (ugly) logic to identify the `__dirname` of the utility script and access fonts relative to the utility itself as opposed to the calling path. As discussed in #24 we will eventually want to remove fonts from the project altogether, instead trying to have a generic default settings and allowing font configuration to be configurable for anybody who would like to override that generic option. Issue #24
Fonts were being loaded in a way that would only work if the script was being called from the mw2pdf root (the folder containing the embedded fonts). This adds some (ugly) logic to identify the `__dirname` of the utility script and access fonts relative to the utility itself as opposed to the calling path. This logic is necessary because unfortunately NodeJS doesn't populate __dirname when module mode is enabled. See: https://stackoverflow.com/questions/32705219/nodejs-accessing-file-with-relative-path/32707530#32707530 As discussed in #24 we will eventually want to remove fonts from the project altogether, instead trying to have a generic default settings and allowing font configuration to be configurable for anybody who would like to override that generic option. Issue #24
Fonts were being loaded in a way that would only work if the script was being called from the mw2pdf root (the folder containing the embedded fonts). This adds some (ugly) logic to identify the `__dirname` of the utility script and access fonts relative to the utility itself as opposed to the calling path. This logic is necessary because unfortunately NodeJS doesn't populate __dirname when module mode is enabled. See: https://stackoverflow.com/questions/32705219/nodejs-accessing-file-with-relative-path/32707530#32707530 As discussed in #24 we will eventually want to remove fonts from the project altogether, instead trying to have a generic default settings and allowing font configuration to be configurable for anybody who would like to override that generic option. Issue #24
First things first: I don't love the way fonts are being used in this project to begin with here and it isn't clear to me we need them.
Anyway, right now the
PdfGeneratorhas ageneratePdfFromScaffoldmethod where a bunch of fonts are registered in thePdfPrinterobject. The problem is is that the font paths break depending on where the script has been initiated from.To make matters worse,
__dirnamedoesn't actually exist in our current setup (this may be fixed by #20). For now we need to do something like https://stackoverflow.com/a/32707530/159522 when defining the font paths in order to call themw2pdfscript from our flask app.The text was updated successfully, but these errors were encountered: