Multilingual label printing in Koha (praise be to Bywater!)
Hi all, I had a problem where I couldn't print Chinese and English on barcode labels using Koha's built-in Label Creator, since it uses individual font files and I couldn't find a free and open individual font that supports both European and Chinese scripts. Fortunately, I recalled that Kyle @ ByWater Solutions created this plugin: https://github.com/bywatersolutions/koha-plugin-label-maker. It uses HTML and CSS to generate labels in the browser, and the browser is already capable of using multiple different fonts to support multiple different scripts. The plugin did a great job of rendering barcodes with both Chinese and English written on them! Thanks, Bywater Solutions, for saving the day! -- Nerdy thoughts: If I look at the "Computed" styles in the F12 tools in Chrome on Windows 10, it says the English is rendered using the "Times New Roman" font, and it says that the Chinese is rendered using the "Microsoft YaHei" font. If I do the same thing in Microsoft Word, the English is in "Calibri" and the Chinese is in "DengXian". If you read https://fonts.google.com/noto/use#how-are-noto-fonts-organized it says "If you have text in multiple languages that use different scripts, either the app or the person who typesets the text needs to switch between the different fonts accordingly." I'm not an expert on fonts, so I'm not sure what would be involved with getting Koha's PDF libraries to use different fonts for different scripts. I don't know how Chrome and Word detect that they need to use a different font. I don't know if it's a map of Unicode codepoints to existing font mappings, or if it iterates through a list of fallbacks, or what. I probably won't go too far down this rabbit hole, since the ByWater Koha Plugin solved my immediate use case, but it's an interesting topic, and this is a major limitation with Koha's Label Creator, so we might want to think about a change in the future... David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595
Yep! the Bywater Solutions plugin by Kyle does the job nicely "outside the box" :-) IIRC the label printing code was last worked on by Chris N a long long time back. As far as I can tell the non Latin printing issue is due to the PDF library we are using. Prolly needs a rewrite for that part which requires both time and funds :-( -Indranil On Thu, 30 Jun, 2022, 12:34 pm , <dcook@prosentient.com.au> wrote:
Hi all,
I had a problem where I couldn't print Chinese and English on barcode labels using Koha's built-in Label Creator, since it uses individual font files and I couldn't find a free and open individual font that supports both European and Chinese scripts.
Fortunately, I recalled that Kyle @ ByWater Solutions created this plugin: https://github.com/bywatersolutions/koha-plugin-label-maker. It uses HTML and CSS to generate labels in the browser, and the browser is already capable of using multiple different fonts to support multiple different scripts. The plugin did a great job of rendering barcodes with both Chinese and English written on them! Thanks, Bywater Solutions, for saving the day!
-- Nerdy thoughts:
If I look at the "Computed" styles in the F12 tools in Chrome on Windows 10, it says the English is rendered using the "Times New Roman" font, and it says that the Chinese is rendered using the "Microsoft YaHei" font. If I do the same thing in Microsoft Word, the English is in "Calibri" and the Chinese is in "DengXian". If you read https://fonts.google.com/noto/use#how-are-noto-fonts-organized it says "If you have text in multiple languages that use different scripts, either the app or the person who typesets the text needs to switch between the different fonts accordingly."
I'm not an expert on fonts, so I'm not sure what would be involved with getting Koha's PDF libraries to use different fonts for different scripts. I don't know how Chrome and Word detect that they need to use a different font. I don't know if it's a map of Unicode codepoints to existing font mappings, or if it iterates through a list of fallbacks, or what.
I probably won't go too far down this rabbit hole, since the ByWater Koha Plugin solved my immediate use case, but it's an interesting topic, and this is a major limitation with Koha's Label Creator, so we might want to think about a change in the future...
David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia
Office: 02 9212 0899 Online: 02 8005 0595
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
participants (2)
-
dcook＠prosentient.com.au -
Indranil Das Gupta