Dataset READMEs and Data Dictionaries from metadata

[alexrichey]

• [x] format data dictionary pdfs
• [ ] add readme metadata to the metadata model and yml
• [ ] generate readme pdfs

[damonmcc]

found an example of our code converting a markdown file to a pdf here

[alexrichey]

@damonmcc Is this the correct issue, or is there another?

[damonmcc]

looking into using weasyprint (already the engine we're using in our use of pandoc) to do html + css = pdf

weasyprint samples here

[alexrichey]

@damonmcc Here's how I'd go about the remainder of this task. Let's chat when you have a minute. In terms of timeline, the next check-in with Amanda+Matt+myself is Thursday next week, and I'd like to show progress on this item. POC/WIP is fine 🙂

Data Dictionary (All fields come from metadata)

• [x] POC of approach basic and ugly, but with some colors, and the DCP logo. Generated from manually created HTML with inlined CSS, fed into weasyprint. Goal is to prove out the approach, and get a sense of the difficulties.
• [x] Create skeleton of Jinja HTML template. Probably start from scratch, but take inspo from Heng's work. Use real product metadata, but don't focus effort on transforming/testing the data.
  • [x] get team feedback on template via draft PR
• [x] Productionize:
  • Make the template look good
  • CSS should probably be in a separate file, and inlined*
  • tests, if applicable
• [x] Implement auto-asset-autogeneration (similar to OTI data dict), and implement in TemplateDB

README

Most fields from metadata, except changelog. Potentially other fields? TBD. e.g. rich text with images.

• [ ] POC of approach basic and ugly, but with some colors, and the DCP logo. Generated from manually created HTML with inlined CSS, fed into weasyprint. Goal is to prove out the approach, and get a sense of the difficulties.
• [ ] Create skeleton of Jinja HTML template with mix of real and mock data (mock the changelog).
  • [ ] get team feedback on template via draft PR
• [ ] Productionize:
  • Make the template look good
  • CSS should probably be in a separate file, and inlined*
  • tests, if applicable
• [ ] Implement auto-asset-autogeneration (similar to OTI data dict), and implement in TemplateDB
• [ ] Figure out where changelog lives (can get going on this whenever, but it's a trivial/minor implementation detail, and it shouldn't block us)

For inlining, potentially use something like this: https://pypi.org/project/css-inline/