[feature] Generate fixed-layout output (PDF or similar)

[nyq]

Harness diagrams, when used in production environment, need to be in some fixed-layout document format because that document needs to go through the design review, approval and release processes. Surely one can take HTML output produced by WireViz and manually "print" it into PDF format, but it would be more useful if the tool had an option for direct generation of PDF. Manually generating PDFs out of HTML is not only adding an extra step, but it also requires playing with scaling factor depending on the size of the diagrams in HTML file. At a minimum, PDF output solution would need to meet the following requirements:

1. User should be able to specify target paper size
2. User should be able to specify target paper orientation
3. BOM table should auto-scale to fit into page width independently of the diagram scaling factor
4. Diagram should auto-scale to fit into single-page dimensions independently of the BOM table scaling factor
5. There needs to be a way for the user to supply HTML files with document header and footer contents (having custom headers and footers is a must for any controlled document)
6. The tool should have macros for page number, current date etc for substitution inside of HTML headers and footers
7. There needs to be a way to override any fixed text currently hard-coded into HTML output (e,g, section headings like "Bill of Materials") for international purposes. Some users need to have them in other languages, while some other users have corporate manual of style that does not allow excessive capitalization of the section headings. Would be great to have this feature for any output, not just PDF.

[kvid]

Please take a look at PR #239 and try out the related branch to test if most of your suggested features will be covered. You can also comment in this PR any outstanding issues to meet your requirements.

[nyq]

Please take a look at PR #239 and try out the related branch to test if most of your suggested features will be covered. You can also comment in this PR any outstanding issues to meet your requirements.

I looked both at PR #239 as well as underlying feature/technical-drw branch, they both crash even when I am trying to run them against the "official" demo project (demo02.yml) out-of-the-box by simply calling wireviz demo02.yml from command line. The error message I am getting is this:

...
File "C:\Users\WDAGUtilityAccount\AppData\Local\Programs\Python\Python311\Lib\site-packages\wireviz-0.4.dev0-py3.11.egg\wireviz\wireviz.py", line 389, in _get_yaml_data_and_path
yaml_path = Path(inp).expanduser().resolve(strict=True)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\WDAGUtilityAccount\AppData\Local\Programs\Python\Python311\Lib\pathlib.py", line 993, in resolve
s = os.path.realpath(self, strict=strict)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<frozen ntpath>", line 696, in realpath
OSError: [WinError 123] The filename, directory name, or volume label syntax is incorrect: 'C:\\test\\WireViz-feature-technical-drw\\examples\\metadata: \n\n  title: WireViz Demo 2\n  pn: WV-DEMO-02\n\n  authors:\n    Created:\n      name: D. Rojas\n      date: 2020-05-20\n    Approved:\n
...

followed by complete dump of the YAML file content (truncated here for brevity).

It seems like a call to Path(inp).expanduser().resolve(strict=True) in wireviz.py:389 fails to raise the exception and instead it just crashes when YAML string is fed into resolve() instead of the path. Am I doing something wrong?

Also, even if I am doing something wrong, it does not seem to be a safe and sound practice to feed the content of an arbitrary YAML file into the file path analysis function in order to try to differentiate between the path and YAML.

[kvid]

I'm sorry, @nyq that I wasn't fully updated on the state of #239. You are right the included demo02 fails in this branch. However, @formatc1702 has joined several of his PRs (including #239) into #251 - where he also makes improvements. The demo02 does not currently fail in this branch, so please try that one instead. Feel free to make comments/reviews in #251 about your findings.