Qucs: add command line option input/output schematic to PNG, SVG, PDF

[guitorri]

Enable users to print schematics to file, from the command line. Besides other benefits, it is ideal for automating the documentation, test the rendering...

See:

• https://github.com/Qucs/qucs/tree/yodalee-issue32-cli-print
• https://github.com/Qucs/qucs/tree/yodalee-issue32-rebase

Actions:

• [x] add options like pagesize
• [x] color / bw
• [x] orientation (portraid, landscape)
• [ ] crop [up, down, left, righ]
• [x] dpi for bitmaps

Currently it does:

qucs -p -i schematic.sch -o printout.[png, svg, pdf, eps]

Current command line interface:

~/buildarea/qucs-creator $ qucs -h
Usage: qucs [-hv] 
       qucs -n -i FILENAME -o FILENAME
       qucs -p -i FILENAME -o FILENAME.[pdf|png|svg|eps] 

  -h, --help     display this help and exit
  -v, --version  display version information and exit
  -n, --netlist  convert Qucs schematic into netlist
  -p, --print    print Qucs schematic to file (eps needs inskscape)
    --page [A4|A3|B4|B5]         set print page size (default A4)
    --dpi NUMBER                 set dpi value (default 96)
    --color [RGB|RGB]            set color mode (default RGB)
    --orin [portraid|landscape]  set orientation (default portraid)
  -i FILENAME    use file as input schematic
  -o FILENAME    use file as output netlist

[yodalee]

I think I can take some survey on this issue.

---

Btw when I search for command line parser, here are some recommended result: Boost.Program_options //I think this is overkill tclap at http://tclap.sourceforge.net //I think this is just fine, just small enough to wrap into qucs.

However, the cmd options is currently not so complex to use library to handle, I think I will focus on the input/output function.

[guitorri]

Thanks for looking into it. I agree with you, focus on the function that creates the output image/pdf is move important than how the command line looks like. Let us leave the command line parser for another issue/feature.

By the way, the existing CLI was added with the commit: 1b817bccff4a80fd7f8389f0757c7039b940a034

Back then I added the comand to input (load) and output (save) an schematic. Just to be able to automate tests (https://github.com/Qucs/qucs-test) and make sure we don't break anything while doing the port to Qt4.

[yodalee]

Actually there is already qt5 My friend write a layout reader all in qt5: https://github.com/aitjcize/QCamber If porting to Qt4 is not under progress yet, maybe directly skip to Qt5?

[guitorri]

The porting to Qt4 is ongoing. The priority is not to break what we have. The strategy is first to get rid of Qt3Support, me and another developers are working on it. It takes time and has do be made right. We need to port the whole schematic to the Qt Graphics framework (the same your friend uses in QCamber). This also takes time. After that it should be rather smooth to go to Qt5. But first we want to stabilize in Qt4 to have it as reference.

[yodalee]

current argument --netlist or -n will transfer .sch to netlist file, so now we wanna add option that output can be other format?

[guitorri]

Maybe we can have : -p, --print convert Qucs schematic into a printable format (derived from -o FILE.[png,pdf])

In the end: $qucs -p -i file.sch -o figure.png

[yodalee]

XDD, we got the same thought, I just add this option 10 min ago. But there is something to be decide, what if user input $qucs -n -p -i file.sch -o figure.png

[guitorri]

It will be cough as an error... no?

[yodalee]

no, but we have do decide the action. the program should transfer schematic to figure or change to a netlist with name figure.png

[guitorri]

There should be only one operation at a time, the '-n' and the '-p' at the same should not be allowed.

[yodalee]

OK I see.

[guitorri]

Maybe something like this:

else if (!operation.isEmpty())
   if (!strcmp(argv[i], "-n") || !strcmp(argv[i], "--netlist")) 
     operation ="netlist";
   else if (!strcmp(argv[i], "-p") || !strcmp(argv[i], "--print")) 
     operation = "print";

It should capture only one operation, if two are given it wont parse, and error out.

[guitorri]

Your PR https://github.com/Qucs/qucs/pull/42 is now on the branch https://github.com/Qucs/qucs/tree/yodalee-issue32-cli-print Let us please work on this branch to develop this feature further.

It is looking good, but if there are Diagrams along with the Schematic they are not printed. It would be nice to have it also printed.

I tried to reuse some parts from here: https://github.com/Qucs/qucs/blob/master/qucs/qucs/qucs.cpp#L3111 I managed to create .png but the Diagrams are also not painted...

[yodalee]

I found the reason of why diagrams didn't show. In schematic_file.cpp :: loadDocument() : 899, it prevent schematic load diagrams and painting if the GUI is not running. I remove the guard and got seg. fault during load file, I think the loading use some GUI only properties, and may be difficult to remove.

[guitorri]

You mean: https://github.com/Qucs/qucs/blob/master/qucs/qucs/schematic_file.cpp#L898 I don't recall exactly why, but did that in 1b817bccff4a8. I guess at that time I was only interested on what was necessary for the netlist.

[yodalee]

This is a little difficult to fix, but I will keep trying to separate the gui part and non-gui part. In the meantime, I think we can first ignore the painting and diagrams, and discuss the further command line argument about other options.

[yodalee]

I just fix diagram error, it use gui font setting in qucsmain, so it raise seg fault when gui is not initial.

[guitorri]

Yep. I also just found it.

This was the traceback while loading a schematci with a rect diagram:

RectDiagram::calcDiagram() + 95 (rectdiagram.cpp:132)
RectDiagram::RectDiagram(int, int) + 134 (rectdiagram.cpp:50)
RectDiagram::RectDiagram(int, int) + 33 (rectdiagram.cpp:51)
Schematic::loadDiagrams(QTextStream*, Q3PtrList<Diagram>*) + 784 (schematic_file.cpp:747)
Schematic::loadDocument() + 2740 (schematic_file.cpp:899)
openSchematic(QString) + 401 (main.cpp:640)

Whit this I got it to render the diagram frame, but not the data on it: https://gist.github.com/guitorri/4c95439e050b878926ab

This is also related: https://github.com/Qucs/qucs/blob/master/qucs/qucs/wirelabel.cpp#L200

Maybe we can handle with the document font differently...

[yodalee]

I just send a pull request, you can see that diagram is being draw ( you have to call update reloadGraph()). I'm now trying to draw painting and symbol, see what will happen. BTW, I wanna ask, how to make <symbol> field got something in there? I try many component, but still got no <symbol> data.

[guitorri]

Nice!

[yodalee]

Now I'm working on painting, I think only Text painting need similar modification. I cannot test on symbol, because I don't know how to create symbol tag. I think you can think about the other arguments about the options to be supported

[guitorri]

The '' is only filled if you create a Circuit Symbol (icon) for a sub-circuit schematic.

Have here a project with sub-circuits: https://www.dropbox.com/s/k120l0deje8rss0/opa27_prj_v1.zip?dl=0

The timelist and truthtable are still crashing the application. Have here the schematics I am using to test the Qt3-Qt4 port. All Diagrams should be represented in here: https://www.dropbox.com/s/4u51ymd5fk6apf2/diagrams_prj.zip?dl=0

[yodalee]

Hi, @guitorri, I print open opa_spice.sch and printing is successful. I think we can close this issue and open another issue for cmd line argument?

[yodalee]

I'm not quite sure what crop [up, down, left, righ] is. I didn't find anything similar in QPrinter property

[guitorri]

Well crop is perhaps a bit too fancy, it was just an idea, perhaps we can skip this for the moment. This can also be done with other tools.

Imagine you want to trim/crop 2cm from the top border, 5cm form the bottom... you could give the amounts you want to cut out. Later on we could fetch the position of individual Diagrams, or a certain area of the schematic, crop them out and build a report for instance...

Note that I could use your code on most of the projects in: https://github.com/Qucs/qucs-test The schematics older than 0.0.10 need to be updated to be printable on the CLI, but there I still want to see if we can get some information about backward compatibility...

Later I hope make the examples web-page more interesting by automatically creating project pages containing their printouts and perhaps some documentation.

[yodalee]

I'm currently working on print in pdf format with argument. After that I'll try to copy the function in qucs.cpp to save data into png and svg format.

---

Btw I wanna say that, you can create as many issue as you can. Since there are nine branches on qucs/qucs, but we know little about what we can do to this project. If you can create issues about what you wanna do/make/achieve and give a clear description. I think there are many volunteers in github can help you accomplish it.

[yodalee]

I think we can merge this into master branch, or wait the re-factor done to eliminate duplicated code.

[guitorri]

Hi @yodalee, I guess one copy is OK, on the 3rd duplication we know we need refactoring... The code is ready to merge in https://github.com/Qucs/qucs/tree/yodalee-issue32-rebase Do you want to add/change something further?

[yodalee]

I think it's fine to merged.

[yodalee]

Maybe the yodalee-issue32-cli-print branch can be deleted? I'm not sure about it.

[guitorri]

I guess it is already deleted. Did you 'git prune' your local?

[yodalee]

My fault XDD