[feature] Export technical drawing to PDF, with frame, title block, BOM

[formatc1702]

No description provided.

[formatc1702]

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:

• making the available 'canvas' for the image properly fill out the frame minus title block and BOM list
• making the page look good both on screen (responsive?) and on paper (fixed A4/A3/A2 sizes) when exporting to PDF
• de-uglifying the current CSS mess
• getting the HTML properly exported to PDF using pdfkit (or suggest an alternative)

Here's a preview of the two demos, in A4 and A3 respectively:

[aakatz3]

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.

[slightlynybbled]

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

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.

[formatc1702]

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.

[slightlynybbled]

Great. Looking forward to next release!

[aakatz3]

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.

[formatc1702]

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.

[stevegt]

@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 stevegt@a48b5b9. 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.

[stevegt]

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

[pherako]

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:

• hash dereferenced to the first line in the changelog
• autopopulated in chronological order

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