Allow custom fonts to be used in the printing of projects

[cdwhitfield73]

Make sure these boxes are checked before submitting your issue -- thank you!

• [ ] Check that you are using the latest version of the app.
• [ ] Check that a similar issue has not already been opened.

Use the custom font that has been selecting by the user in the generating of the pdf

Based on https://github.com/unfoldingWord-dev/ts-requirements/issues/118

[cdwhitfield73]

While the PDF will technically "use" any font that is set as the target translation font, some custom fonts will not render properly. We have found this to be an issue with many of the fonts included in windows, but believe that most fonts a user will download specifically for their language should work

[cckozie]

It doesn't look like the print process is using the available fonts. I have set the target translation to Noto Sans. I have an OBS project with the target set to ur, which is also the source language (I think). Here is a screenshot from the app.

This is the pdf output from the tS print function: ur_obs_text_obs.pdf

This is the output from printing a web page from the unfoldingWord.org website of OBS in the ur language. obs.pdf

[cdwhitfield73]

So, I think the issue here is the same as we had before. Noto sans does not work for non-Roman characters in printing, even though it works in the app. This is the whole reason we added the ability for the user to add custom fonts to the app. In order to really test this out, you need to download a custom font (perhaps one designed to work for a particular non-Roman language), select it as the target translation font, and then create the pdf.

[cckozie]

I have tried a variety of approaches to testing this, and none of them provide the desired results. The closest I have gotten was to copy some of the OBS target text into Word and let it choose the font. If I then print from Word, I see exactly what was in the OBS target text. If I print it from tS, it is close, but still contains a few boxes rather than some of the characters. The attached file contains the tS project and the pdf output files from tS and Word. Look at the first paragraph on page 6 of the OBS print to compare to the pdf from Word and the tS project. hu_obs_text_obs.zip

[cckozie]

Per the user story in Discourse, I installed and used the font family from here: http://urdu. I tested a couple of ways, one using the farsi version of OBS, and the other using urdu. In both cases, the text within tS looked fine, but the pdf was completely unrecognizable. fa_obs_text_obs.pdf ur_tit_text_reg.pdf

[klappy]

@cckozie Thanks for digging into testing the specific use case of the user. It appears that the printing using custom fonts won't work for our intended use case. Either we roll out support for just the UI and later for printing, or wait until it works in both. Technically the user did not reference printing or I failed to capture that, but I do assume that would be expected with the feature. I have a question out to Alex the user that the request started with, asking him if UI custom fonts will suffice, and later release printing.

[cdwhitfield73]

@klappy At this point, removing the UI portion of the new font process would be messy and time consuming. I recommend we leave it as is and continue to work on getting the fonts to work in pdf's for next release.

[klappy]

Big picture, Until the feature is completed, I'd rather not officially release it until completed. If however, the user claims that UI is the only need, or will suffice for now, then we can separate the two. My gut tells me they are expecting both and will not accept just UI. (Keep in mind that testing revealed the need for the shift as it was expected to work for Google webfonts but did not work for the specified font from the user).

[cckozie]

This is really bad! Here is a print from Philemon with Comic Sans font: en-x-demo1_phm_text_udb.pdf

[cckozie]

In testing 9.1 (both Windows and OSX), when Times New Roman is selected as the target font, it is used in printing, but the print is italicized.

[tjklemz]

^^ I had not seen that. It may be necessary to do a full rework of how printing works.

[cckozie]

weird results when printing merged project with conflicts. Using Comic Sans font. en-x-demo1_3jn_text_reg.pdf After removing the Head>>>> text it gets better: en-x-demo1_3jn_text_reg.pdf

[cdwhitfield73]

So our PDF library clearly does not work with most fonts. For now, I have changed it back to only using Noto, which still won't work for some languages, but will for most. We need to discuss how or if we want to move forward with solving this problem, as any option will take a bit of work.

[cckozie]

Marking as QA Passed since Noto is now always used for printing. Added issue 794 for future refactoring.