Make more cards fit on a single page.

[sumpfork]

Especially for some full bleed printers lots more can fit if they're rotated.

[wvoigt]

Some thoughts on this. If the wrappers / slipcases from #48 come into being, then each card will have a different height (the width is the same). That said, after prototyping the code for the wrappers and printing the back side of the wrapper rotated 180, I think having an option to print cards at 90 is very possible.

So part of the algorithm could be to (a) look at all cards rotated 90 to see if more fit that way, and (b) look to see if one card could be added by rotating just it 90 (a mix and match.) Not sure if you ever really need more than 1 card in the other orientation.

[wvoigt]

More thoughts on this... Wondering if refactoring the code in draw.py a little would help in the implementation.

drawDividers: Currently this does a simple splitting of cards into pages. Suggest replacing line cards = split(cards, self.options.numDividersVertical * self.options.numDividersHorizontal) with cards = self.pageOptimize(cards, self.options) and instead of relying on simple x, y based on card number on page have pageOptimize return page lists where each card has the following information: [card, x, y, rotation, [crop_left, crop_right, crop_top, crop_bottom]] where: x and y are offsets from the page 0,0 (after taking into account any margin) rotation is 0, 90, 180, 270/-90. Basically x,y is still lower left of card on page, but the card is rotated. and the crop_xxxx are flags for the crop marks to be displayed for that particular card.

So the hard work is moved to pageOptimize to figure out how many cards and where they are located on a page. Initially, pageOptimize can be set to mimic today's behavior. It is a starting point. Over time, other layouts can be added and which ever one fits the most cards based upon the settings can be returned. For example, do nine dividers fit on a page if horizontal dividers are all rotated 90? Same for vertical cards? Or for horizontal dividers, can one (or two) more dividers fit on the right if they are rotated 90? Or if you have vertical dividers, is there enough room to add one (or two) at the top rotated 90? And if someone wants to get real fancy, if the divider tab is less than 1/2 the width of a divider, can more dividers fit if cards are rotated 180 with the tabs interleaved.

With pageOptimize doing most of the hard work, the other parts of the code are then simplified. For example, in the rest of drawDividers, there is no longer a need to calculate x, y (it is returned by pageOptimize)

drawDivider: x, y changed from index position on page to true x,y coordinates of card based on existing (0,0). And add the rotation and crop_xxxx flags. So this function sets up the card so that it's lower left corner is at the page's (x, y) with the given rotation. It would also have to take into account drawing the back side of a divider. So the rest of the divider drawing functions need only assume (0,0) is the lower left of the card.

drawOutline: since x,y was only used to figure out what crop marks to display, remove those parameters and add the crop_xxxx values. It might make sense to combine the crop marks into a function that actually either draws the outline, or draws the crop marks.

Just some thoughts. Wanted to write this down and discuss to make sure not going off into a wrong direction.

[wvoigt]

Here's a sneak peek at an implementation of the above: wvoigt/dominiontabs/RefactoredDraw I am interested in comments. It is a big change. So I don't want to go too much further unless it is felt I am somewhat on a good path.

There were several objectives for these changes:

• Allow dividers to be placed anywhere on a page, in any ordinal rotation. This includes flipping individual dividers from the front of the page to the back of the page.
• Improve the layout efficiency of the dividers on the page. The added improvements include:
• (a) checking to see if rotating the dividers allows more to be printed on a page, and (b) checking to see if there is enough room to add one extra set of cards in another rotation.

Other improvements include:

• Having an object for each divider that contains all the printing information pertaining to that divider. This includes the card information, it’s x,y, rotation, tab side, what text to display on the front/back, if it is on one of the outer edges of the page (and hence might need crop marks), the line type of the outline, etc.
• Crop marks integrated into the card outline. They move/rotate with the card. A translation helper is provided that takes the rotation of the divider along with the page edge information to determine when crop marks are included. When an extra rotated row of cards can be printed on a page, that extra set of cards will have their own set of crop marks.
• A more self contained plotting routine. This make the calculations for all the card outline and crop marks much easier. Basically lines are drawn from current point to next point. The plotting routine keeps up with where everything is on the canvas. Without this, the calculations for the outlines, with the many variations, becomes very complicated. It also includes a helper for drawing the crop marks.
• A new option to have dots printed at each vertices of the divider. This is a compromise between a full line outline and using crop marks. It is also possible to have dots and crop marks. Often, when cutting out dividers, at least one set of crop marks must be cut off, or inner corners are not easily distinguished. By having the dots, it is easy to see exactly where to stop the cut.
• Implements request from Issue #70

What has not been done:

• While the ground work has been put in place, the layout optimizer does not yet try to save space by interleaving the tabs (when the tab width is less than ½ the divider width.) But the infrastructure is there to rotate, move, and flip dividers as needed.
• The layout optimizer does nothing special for wrapper/slip covers. Because the height of the dividers vary, to fully optimize the wrappers/slip covers, the optimization layout needs to be done on a page by page basis. Currently it assumes the height is the tallest divider (Copper).
• Automatic Continuous Integration tests need to be updated.

Original --outfile test-demo-letter-vertical-original.pdf --orientation vertical --papersize LETTER --tab_name_align edge --linetype line --tab_side left-alternate test-demo-letter-vertical-original.pdf

Optimized with Dots, using front/back flipping to alternate tab side --outfile test-demo-letter-vertical-optimized.pdf --orientation vertical --papersize LETTER --tab_name_align edge --linetype dot --optimize --tab_side left-alternate-text test-demo-letter-vertical-optimized.pdf Note the extra divider at the top. Also left/right alternation was done by flipping the divider front to back.

Same as Optimized above, but with slightly smaller margins --outfile test-demo-letter-vertical-optimized2.pdf --orientation vertical --papersize LETTER --tab_name_align edge --linetype dot --optimize --tab_side left-alternate-text --minmargin 0.7x0.7 test-demo-letter-vertical-optimized2.pdf Note the dividers are rotated, and thus more fit on the page. Also left/right alternation was done by flipping the divider front to back.

I've also noticed that in some cases, more dividers can fit on a page if the following is used: --minmargin 0.7x0.7 which corresponds to the minimum 0.25 inch margin many printers recommend.

[wvoigt]

I updated wvoigt/dominiontabs/RefactoredDraw with support for wrappers. In some cases this can reduce the number of pages quite a bit. Also added a new PageLayout class to localize things having to do with page layout information. That cleaned the code up quite a bit.

I have started implementing a few routines for interleaving cards. Can now interleave two cards. The hard part is (1) predicting how many interleaved cards will fit, and (2) figuring out the order and direction for interleaving. The prediction part may have to be iterative similar to the wrappers. But things like centered tabs on expansion dividers can mess things up (can't interleave those).

Here's an example of the wrappers test-demo-A3-horizontal-wrapper-optimized2.pdf

Please let me know if you have comments on the direction this is going, or the way I have chosen to implement it.

[sumpfork]

Hi @wvoigt, sorry about my slow responses at the moment but both home and work have been intense with new babies and new companies. I'll try to get to reviewing all this this week if at all possible, thanks for all your work!

As one general comment: I wouldn't spend too much time on maximizing the number of cards per page at arbitrary rotations/interleaving. It generally makes them harder to cut, both for the home-cutting and professional cutting cases, so I'm not sure how many people would use it. I was mainly thinking about adding two rotated ones or similar where they fit on the side so that they're still easy to cut but save a bunch of pages.

All the refactoring and stuff still looks promising though - as said, I'll try to get to looking at it in detail soon. Still have to update the online generator with your previous work, too. And I'd like to make the online generator code public, too, so that others can start exposing options there - I feel like too much of a bottleneck.

[wvoigt]

@sumpfok, no problem. And congratulations on the new job and especially the new babies! I fully understand. To be honest, I have been only working this in bits as well, so I needed the extra time.

As for all the rotations/interleaving, in truth the hard work is almost done now. I just need to spend some time on the dividers per page prediction, some margin setting, getting the options setup, updating the self tests, and cleanup. Although there could be lots of that :-)

Much of what I was doing was trying to maximize the number of wrappers on the page, similar to what hgzwopjp had done. Even fitting one extra on a page can make a difference when only 2 or 3 are normally printed per page. That said, the intent is to have options for everything. So folks can use or not as they want. Here's a recent A3 with wrappers interleaved:

[wvoigt]

Unless there is an objection, with the card_db refactoring done, I plan on bringing this code base up to date with the latest master. Instead of putting it elsewhere, I would like to put the branch here, so it is easier for others to see and comment.

I also hope to pull in code for:

• 70 "Option to print alternating tabs in same orientation"

• 85 "3 tab option"

both of which are much easier to do with the updated code in draw.py.

I'll also add in #120 "Add a command option to include a page in the pdf with the options used".

@sumpfork, before I go too far with this, any other major code restructuring on the horizon?

[sumpfork]

I'm going to work on automating deployment, and I hope that the only thing I needed was for the package to be properly installable. That said, I haven't gotten very far yet, but I don't think there should be major code movement happening in the process.

[wvoigt]

While it worked, I was not happy with the way the optimizations were done. So I'm taking a step back. Pull #150 adds a lot of the supporting infrastructure, but without the actual optimizations. I will continue to look at better ways to optimize.

[RubeRad]

First off thx sumpfork for this excellent open source project, and thx wvoigt for contributing.

I know, it's not a big deal to print a couple extra sheets, but the pdf I made from the website had 6 dividers per sheet, totaling 13 sheets, and I found I only had 11 sheets of cardstock left! Using the python version (from pip), just setting --minmargins 0x0 switched to landscape (letter) and fit 3x3 dividers per sheet (not even interleaving tabs, so keeping easy cutting), and reported margins still of 0.32cm and 0.60cm.

Maybe that should become the new default?