exporting/printing logbooks

[dschick]

exporting/printing logbooks

[johanfforsberg]

There is some limited functionality to export a logbook as PDF. It was hacked together just as a proof of concept and it's fairly untested. In fact I just noticed it was a bit broken, you will have to pull
master to get the fix. It also requires https://pypi.org/project/pdfkit/

It's not exposed in the UI at this time. Ypu can use it like this:
wget http://localhost:8888/api/logbooks/1/entries/?download=pdf

Try it and see if it solves your use case, otherwise feel free to report an issue with your findings. Exporting as a simple HTML file could also be an idea.

[dschick]

Hej,

somehow I only get an empty pdf file returned.
I added the pdfkit and wkhtmltopdf to the requirements.txt file of the backend and rebuild the docker image.

Btw: what do I need to do in order to take any changes in the backend-source take effect in docker?

I am running a docker-compose build and docker-compose up -d but it seems my changes don't have any effect.

Best

Daniel

[johanfforsberg]

Hmm, I see the same thing, but only when running in docker compose. Interesting, could it be that nginx or uwsgi somehow strips it out? I'm not really the expert on those parts of the system though. But I'll have a look.

By the way, I found a flag to wget that keeps the logbook name of the PDF file:

wget http://localhost:8888/api/logbooks/1/entries/?download=pdf --content-disposition

Anyway, for development, I run the backend locally with:

cd backend
FLASK_APP=backend.app ELOGY_CONFIG_FILE=$(pwd)/config.py env/bin/flask run -p 8888

and then to get the frontend up, in another shell

cd frontent
npm start

The UI should be available on http://localhost:3000. Look in the readme for some clues on how to install locally if needed. If you want to play around with the PDF export that might work better.

[johanfforsberg]

By the way, the commands to rebuild the docker images work fine here, but I find that it's more helpful to skip the "-d" switch to "docker-compose up" while testing, since then you can see logging output directly in the shell.

[johanfforsberg]

OK, I think the problem is with the version of wkhtmltopdf in the image, it errors out with a message about not being able to connect to a display. Probably the same issue as wkhtmltopdf/wkhtmltopdf#2037 :(

That's annoying. I'll try to come up with a solution, but as far as I can remember pdfkit didn't seem like a perfect solution anyway, just the easiest to get working. So maybe it's a better idea to look for something else.

[dschick]

thanks a lot for debugging!

I would be also fine with a printer-friendly version as html.
I guess this is much simpler and their might some more json2html parsers available in python.

[johanfforsberg]

Yes, in fact the current PDF export converts to HTML fists and then turns that into PDF :) The body of the entries are stored as HTML anyway so the conversion is trivial. A "download=html" feature should be easy to implement, it essentially just needs to skip the pdfkit step.

[dschick]

okay, let me check if I can handle it myself

[johanfforsberg]

Please make a pull request if you get something working!

Looking at the code now, I think the main part that's missing is handling of image attachments. For HTML export they probably need to be base64 encoded and inlined directly in the document instead of linking to the files.

[dschick]

álright, so wget is fine, then it seems, that it is a firefox issue?
Also in firefox there are new files(names) saved under /tmp for every export, but their content is the same or somehow cached

[johanfforsberg]

Ah, I did not try with a browser. I see the same thing with firefox.

I wonder if it's caused by some response header ("Cache-Control: public, max-age=43200") which is probably set by nginx. I'm not sure that affects downloaded files though.

This header can also be inspected with "wget -S", but since wget doesn't cache stuff between runs, it won't affect it.

[dschick]

okay, I started to play around with the nginx setting. I guess it would be smart in general to disable any caching for the api location, right?
However, I am not sure how to get rid of this default header Cache-Control: public, max-age=43200
I added Cache-Control: no-cache but without the other line disappearing

[johanfforsberg]

(Answered from my work account by mistake, re-posting to be less confusing :)

Thanks for investigating, I don't have time to look into this right now but maybe it's actually flask that generates this header somewhere in the "send_file()" response. It's only really for attachments where it would make sense to cache responses, so we can definitely turn it off elsewhere.

https://stackoverflow.com/questions/23112316/using-flask-how-do-i-modify-the-cache-control-header-for-all-output

[johanfforsberg]

Please have a look at PR #16!