Open formatc1702 opened 4 years ago
Started some work in the feature-pdf
branch.
html2pdf.py
reads template.html
and replaces some placeholders with the data from metadata.yml
and creates output.html
, which includes the image harness.svg
. This could subsequently be turned into a PDF using the pdfkit
package, but that is still a work in progress.
The title block is based on DIN 6771, without the top row(s). Customization with different title blocks is easy, just replace template.html
.
The information currently stored in metadata.yml
will just become a new section in the wireviz input file, above or below connectors
, cables
and connections
.
BOM should be rendered as a separate table and placed above (for A4 portrait) or to the left (for A3/A2 landscape) of the title block (also work in progress)
Preview:
If anyone proficient in HTML/CSS wants to help me improve the output of the technical drawing, please check out the feature-pdf
branch and contact me!
Main issues:
Here's a preview of the two demos, in A4 and A3 respectively:
Ideally, this should be rendered as a PDF/E type of document, the engineering subset. I think it supports inserting blocks, and may even have title block classes but I am not sure.
I also fiddled with pandoc a bit to see how the direct HTML conversion to PDF would look and it looks good enough for most purposes. Doesn't have the nice sign-off blocks, but it is easy.
$>pandoc test.html -o test.pdf
I suspect that a very nice drawing is not a version 0.2.0 type of hold up. The ability to export the PDF satisfies most users' needs and is appropriate for a v0.2.0 release. I only bring this up b/c it seems like the feature appears to be a significant barrier to the next release.
Edited to add: Changed the html image to the generated test.png
in order to get pandoc to properly import the image.
I suspect that a very nice drawing is not a version 0.2.0 type of hold up.
it seems like the feature appears to be a significant barrier to the next release.
It is by no means a hold up, the only thing I'm waiting for is the multicolor wires.
Great. Looking forward to next release!
Update on the PDF/E thing/suggestion/note: The main reason to consider PDF/E, or additional features rather than direct HTML (granted, I haven't yet looked at the code) would be to use the different layers. Ideally, the wires, tables, BOM, and title block would all be on separate layers to allow for easier engineering management, if someone were to, for example, import the PDF into autocad, to generate a pegboard manually. I will try to look through the code soon, and the pdfkit documentation, to see if there is any easy way to specify layers for the images/bits.
While this is a good idea in principle, I am unsure about the immediate usefulness. See my comment in #61, proper pegboard output would be a MASSIVE undertaking that I don't see happening anytime soon.
I'd rather focus on getting something pragmatic and good looking in the short term.
@formatc1702 This is awesome! I was about to hack together something similar and then found this issue -- I've merged your changes from https://github.com/formatc1702/WireViz/tree/feature/technical-drw into my own https://github.com/stevegt/WireViz/tree/drawing, which is otherwise current dev + #171.
That should give anyone a starting point if they want to bring this feature into 0.3 or even sooner -- I'd start by applying the diff from https://github.com/stevegt/WireViz/commit/a48b5b936ca69bc010b04018343b3b60f8bfd22e. The merge wasn't too ugly -- ignore the html deltas; the important deltas are in Harness.py, template.html, and wireviz.py. Example usage is in the new metadata section at the top of a couple of the example .yml files.
The results are working for my use case so far. About the only thing I would change is the way the template.html is handled -- there's an older note in Harness.py about finding it from yaml or cmdline, and I also think we should continue the legacy hardcoding of a default html string to handle the case of no template file at all.
If anyone needs a simplified title block, no BOM, US letter landscape, and only one revision row, here's a stripped-down version of template.html that does all that: https://gist.github.com/stevegt/cfd67d2df424e1b5a1ea4e0619b3f90e
It would be pretty cool if you could specify git hashes to become changelog entries in the block as well as other pieces. I'm not sure git integration was on your roadmap, but here are some ideas. The nice thing about wireviz yaml is it's version able, and git is a great versioning tool.
Here's a way:
proposed syntax:
title_block:
- type: ansi #not sure what y'all are doing here
- git_changelog: ea7fece5 deadbeef
- git_descriptor: 1
- git_version: 1
git_version
would be GITHASH_LC=$(git log -n 1 --abbrev=7 --format="%h")
albeit i'm personally partial to the commit count since tag, since those are monotonic like svn used to be (dinosaur here).
git_descriptor
more useful imho (bash)
GITHASH=$(git log -n 1 --abbrev=7 --format="%h")
GITDIFF=$(git diff HEAD)
COMMIT_LAST_TAG=$(git rev-list --tags --max-count=1)
COMMITS_SINCE_TAG=$(git rev-list ${COMMIT_LAST_TAG}.. --count)
if [ -z "${GITDIFF}" ]; then
printf "${COMMITS_SINCE_TAG}-${GITHASH}"
else
printf "${COMMITS_SINCE_TAG}-${GITHASH}-dirty"
fi
Here's some sample code to generate a DIN 6771 title block in code...