I was planning on combining thick lines (--linewidth 3 or similar) with --black-tabs. But setting a thick --linewidth makes for ugly corners as the lines don't meet up properly (see example below). This can easily be fixed by printing both lines and dots (though dot size should be set to near 0 if line” in options.linetype) I modified the code and it worked well enough for me with simple dividers (though I haven't tested thoroughly for all situations). It's a simple fix, and have attached a modified draw.py ( draw.zip ) (I haven't installed git, so can't make a pull request, sorry)
Comparison between adding the added dots or not can be seen below:
dominion_dividers (thick lines, all the wrong things).pdfdominion_dividers (thick lines, some of the right things).pdf
Also, I found that if you combine --black-tabs with --linewidth 3, you'll see the line is stepped below the black tab, as the line isn't extended below the tab. So I wondered if a line could be added/extended under the tab, with the condition that options.black_tabs==True. (I don't know how to add this to the code though, though I guess it isn't difficult.)
And if I can add some more remarks on thick lines: the linewidth affects--size as half of the line is drawn outsize the --size, it seems as well as overlap with neighboring dividers. I'm guessing this calculation can be done by recalculating --size (i.e. No major overhaul to the code, just a bit of (re)calculation before the size goes to draw.py) and maybe include --vertical-gap and --horizontal-gap to get rid of the overlap. It can also get a white line to seperate the dividers for easier cutting. (Either by default, though you can leave that as a suggestion, warning. No idea about the ratio between linewidth and cm though.) Comparison examples can be seen in the PDF's above (although I manually adjusted the gaps)
EDIT: Once I printed it, the corners were all messed up. The corners looked good on the PDF (firefox) (once zoomed in). I guess it's hard to troubleshoot what went wrong for my printer, and there's no saying what will happen for other printers. I'll leave it up to you guys, but I think this 'issue' can be closed, as don't really see a proper/fast/clean way to solve this.
I was planning on combining thick lines (
--linewidth 3or similar) with--black-tabs. But setting a thick--linewidthmakes for ugly corners as the lines don't meet up properly (see example below). This can easily be fixed by printing both lines and dots (though dot size should be set to near 0 ifline” in options.linetype) I modified the code and it worked well enough for me with simple dividers (though I haven't tested thoroughly for all situations). It's a simple fix, and have attached a modified draw.py ( draw.zip ) (I haven't installed git, so can't make a pull request, sorry) Comparison between adding the added dots or not can be seen below: dominion_dividers (thick lines, all the wrong things).pdf dominion_dividers (thick lines, some of the right things).pdfAlso, I found that if you combine
--black-tabswith--linewidth 3, you'll see the line is stepped below the black tab, as the line isn't extended below the tab. So I wondered if a line could be added/extended under the tab, with the condition thatoptions.black_tabs==True. (I don't know how to add this to the code though, though I guess it isn't difficult.)And if I can add some more remarks on thick lines: the linewidth affects
--sizeas half of the line is drawn outsize the--size, it seems as well as overlap with neighboring dividers. I'm guessing this calculation can be done by recalculating--size(i.e. No major overhaul to the code, just a bit of (re)calculation before the size goes to draw.py) and maybe include--vertical-gapand--horizontal-gapto get rid of the overlap. It can also get a white line to seperate the dividers for easier cutting. (Either by default, though you can leave that as a suggestion, warning. No idea about the ratio between linewidth and cm though.) Comparison examples can be seen in the PDF's above (although I manually adjusted the gaps)EDIT: Once I printed it, the corners were all messed up. The corners looked good on the PDF (firefox) (once zoomed in). I guess it's hard to troubleshoot what went wrong for my printer, and there's no saying what will happen for other printers. I'll leave it up to you guys, but I think this 'issue' can be closed, as don't really see a proper/fast/clean way to solve this.