macOS PDF build issues: long arguments not accepted & missing fonts in PDF about rootstock HOT 15 CLOSED

I also see the squares in manuscript.pdf in my PDF viewers.

from rootstock.

I am going to close this issue because discussion has become too diffuse. To summarize, the issues that have been discussed are:

1. shell commands with long arguments that aren't supported on macOS. This was fixed in #123
2. generated PDFs that are missing fonts, due possibly to old versions of pango and/or due to the lack of fonts getting embedded in the PDF.
3. An issue with Symbol not found: _clock_gettime

I don't think 2 or 3 have been solved, but they may have been with updates. If you're still getting them, please open a new issue so we can keep things focused.

from rootstock.

Interesting regarding pango. It looks like we could add pango to environment.yml so it gets intsalled using conda for macOS and linux.

Good to know about the long arguments not working on macOS (which OS version BTW)?

Those warnings are from WeasyPrint and are not a problem (they are always there).

And generated PDF has squares only.

Not sure what you mean? The PDF is all garbled? Can you upload it to this issue? Would also be interested in whether the linux generated PDF from Travis has the issue or is okay.

from rootstock.

I can confirm that on MacOS 10.11.6 the long arguments do not work.

from rootstock.

(which OS version BTW)?

MacOS 10.13.3

Can you upload it to this issue?

Would also be interested in whether the linux generated PDF from Travis has the issue or is okay.

Travis is ok.

from rootstock.

Regarding pango, the Travis Linux builds have the following warning (example build):

/home/travis/miniconda/envs/manubot/lib/python3.6/site-packages/weasyprint/fonts.py:43: UserWarning: @font-face support needs Pango >= 1.38
  warnings.warn('@font-face support needs Pango >= 1.38')

I haven't noticed any issues with font-faces in the output PDF, so we haven't added pango to the environment. I don't think we neccessarily need to install pango, unless we see any rendering issues related to @font-face support. @adebali were you having the issues with the squares prior to installing pango with brew?

Could you drag and drop the PDF into a GitHub comment below (GitHub should automatically upload it)? This will help us diagnose whether the issue is with:

• your PDF viewer
• WeasyPrint and how it generates the PDF

Also if not sensitive, can you link to the repository where you're having these issues?

I'll get to fixing the shell commands macOS compatibility.

from rootstock.

@adebali were you having the issues with the squares prior to installing pango with brew?

It was not possible to run build.sh before installing pango with brew.

manuscript.pdf

from rootstock.

I also see the squares in manuscript.pdf in my PDF viewers.

Me too. It's showing up as rectangles on Linux.

Tagging @liZe who has helped me with a WeasyPrint issue before (thanks!). @liZe do you have any idea why the PDF @adebali is generating on macOS using WeasyPrint (called through Pandoc) shows all characters as rectangles? Are there any common issues that would cause this weird outcome?

from rootstock.

Are there any common issues that would cause this weird outcome?

Yes!

With recent versions of WeasyPrint, we use fontconfig to find available fonts on the system. fontconfig needs to have a list of installed fonts, and this list can be updated using a tool called fc-cache. fc-cache is usually called when fontconfig is installed with homebrew, but for some reason the font cache may be empty for you. Try to call fc-cache -frv (that's what's called by fontconfig's package when installed), it should fix your problem.

from rootstock.

I followed the instruction and called fc-cache -frv then I did sh build/build.sh. I am still getting the same pdf.

btw, @dhimmel the repo is here: https://github.com/adebali/manutry

from rootstock.

There's no font included in the PDF file, that's why you get these squares. If you use Pango < 1.38, you can try to either remove @font-face rules or force a font-family and see if it helps.

from rootstock.

So I'm not sure @adebali why you're having the font issues. We've discussed a bit before about having a Dockerized build and setup environment. @adebali have you ever used Docker? If we created a Docker image, it would reduce the number of environments we need to support from unbounded to one. It would also help us with debugging user issues.

Will keep this issue in mind, but it'll probably take several weeks before we can roll out the Docker infrastructure. @adebali in the meantime, you could try using the webapp view locally and relying only on Travis for generating the PDFs.

We are very glad to have you as a Manubot user and are thankful that you're helping us iron out these early hurdles!

from rootstock.

I have a similar problem on OS X 10.11 (Linux works fine)

ImportError: dlopen(/Users/robert/.local/miniconda3/envs/manubot/lib/python3.6/site-packages/PIL/_imaging.cpython-36m-darwin.so, 2): Symbol not found: _clock_gettime
  Referenced from: /Users/robert/.local/miniconda3/envs/manubot/lib/python3.6/site-packages/PIL/.dylibs/liblzma.5.dylib (which was built for Mac OS X 10.12)
  Expected in: /usr/lib/libSystem.B.dylib

I guess this is due to the earlier OS version, maybe related to this? https://stackoverflow.com/questions/2418157/ubuntu-linux-c-error-undefined-reference-to-clock-gettime-and-clock-settim

Anyway, a BUILD_PDF version like BUILD_DOCX would probably be helpful - I don't need the PDF for local development.

from rootstock.

I have a similar problem on OS X 10.11 (Linux works fine)

I'm not sure whether it's similar. Are you saying the error happens at the PDF build stage? Does it result in the blank boxes or does it cause the build.sh script to fail and exit?

Not sure whose responsibility the Symbol not found: _clock_gettime error is. Refs pocoproject/poco#1453. However, it makes me more convinced that Docker is the right solution here. But I need to think exactly how we want to manage and distribute the Manubot environment and whether Docker would make the environment more difficult to customize.

Anyway, a BUILD_PDF version like BUILD_DOCX would probably be helpful - I don't need the PDF for local development.

Noted.

from rootstock.

I'm not sure whether it's similar.

Yes, sorry I meant similar as in "also on Mac" ... the --symbolic problem was how I found this.

from rootstock.