foosel / cardfoldr Goto Github PK

Problem

Currently that requires selecting each PDF individually, starting card extraction and pdf generation. That makes for many a click when wanting to process a whole bunch of files.

Solution ideas

• Some kind of "auto run" checkbox button that will automatically extract, generate & download on file change
• Supporting multiple source PDFs (could get tricky with the back side one... or maybe that just means we need to support multiple files that can be marked as "front" and "back"?)

Problem

Some source PDFs have the individual pages slightly misaligned to each other, so the grid defined on one page will not match another.

Solution ideas

Custom grid start settings per page? Requires some UX solution.

Problem

when handling non-A4 pdfs, 1-2 more decimal places would be nice. I tried to give a margin of 0.635cm (1/4") and it wouldn't accept it...

• Source

Solution

HTML number inputs don't allow a separate step size for validation and the +/- buttons, and thus it's currently set to 0.1mm to allow a quicker adjustment turn around at the cost of some decimals. But I guess I could just create a custom input with two buttons that increase the current value by .1 while still allowing 3 decimals or something.

This would also tie in with the "combining several pdf into one"
I got some expansions for one game which consist of only one card. So the author made them foldable but placed the single cards front side long edge to long edge with the backside. I also have one game were 4 cards are on one page but they are also arranged long edge to long edge in a 2x2 card pattern. If we could get a "backside is on the same page" option and then the appending of several pdf into one that would be great!

Problem

The files its creates are hugh! A 2.4Mb file comes out as 23.2Mb...Maybe a files compression thing, and also not very high on the list given the size of todays harddrives, but nonetheless...

• Source

Solution

Apparently that's a known and so far unsolved issue with pdf-lib, see for example Hopding/pdf-lib#1338.

A first test on the command line with

ghostscript -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 \
    -dPDFSETTINGS=/printer -dNOPAUSE -dQUIET -dBATCH \
    -sOutputFile=output.pdf input.pdf

showed very promising results however, reducing a generated PDF from 55MB to 5.7MB.

It might be possible to get ghostscript to work via wasm and use that to optimize the PDF, as demonstrated by laurentmmeyer/ghostscript-pdf-compress.wasm. The downside of that is having to download the ghostscript wasm build, which is around 18MB. But compression could be made optional with a checkbox and things only loaded if necessary.

Problem

The PDF currently gets generated in the main thread, which obviously causes the whole page to halt. If the process takes too long, the browser will warn that the script seems to be stuck, suggesting to abort it.

In addition, there's no way to give progress feedback while this is going on.

Solution

Move the whole PDF generation into a web worker, sending progress updates per card back to the main thread, and finally the full PDF once generated.

This would ease the access to these bars and reduce the need for scrolling when the zoom factor is high enough that the top part of page/card are not visable when using the sidescrollbar.

Problem

Saveable settings would be great too, i am a patreon of ButtonShy games and have a metric ton of files to process. They have only "recently" switched to a consistent format...

• Source

Solution

• Allow the user to persist/reload the current settings under some name (writing to local storage, should of course also support deleting a profile)
• Maybe also have some predefined presets that could be user contributed (e.g. for certain publishers)

Problem

There are now so many settings and possible combinations of them that it gets a bit confusing when you don't have happened to written the thing yourself.

Solution ideas

Add some included documentation, e.g. in modals that can be opened by clicking on a "?" or something, that explain

• the various card back options
• the various margins in grid settings and PDF generation
• the basic ideas behind the algorithm that decides how to orient the cards on the foldable page
• vertical vs horizontal fold lines and when to use what
• ...

Problem

page selection like the card selection with clicking the black bar would be way more effective...

• Source

Solution

Implement clicking, toggle css class, calculate new page selection string from that and write it back to the input.

Problem

maybe a renaming feature, in case some files have different setting on some pages, it is usefull to set different names for the different parts of the file

• Source

Solution

Provide a name input that gets prefilled from the source PDF's name but can be modified, use that for generating the download name.

Please describe the problem you are facing.

The layout settings does not seem to accept 0 as a value. If 0 is entered it ignores it and reverts to default (?).
This is not an issue for printer margin since that should never be 0.
For card/fold margin it is sometimes wanted to have it set to 0.

Current workaround is to set value to 0.1

Problem

Some source PDFs have misaligned card columns or rows apparently on some pages.

Solution ideas

Column/row offsets? Kinda ugly, should be advanced settings. However, very low priority as I'd say those are definitely very broken PDFs to begin with. And the question of UX is even more unclear than #6

Problem

I dunno if it's possible: put a resize of the output cards... If source pdf has irregular sized cards, like mine, and if you wish to put directly in a standard size.

• Source

Solution ideas

• Add standard sizes to card extraction
  • If card is to big, downsize
  • If card is too small, offer centering and extending

Please describe the problem the feature is supposed to solve.

There are now plenty of options with regards to card extraction, and it's becoming harder and harder to test the possible combinations by hand, leading to bugs creeping in.

Describe the solution you'd like

Add an automated test suite, e.g powered by playwright.

Some basic pdfs with coloured cards could be created as test resources which could then be used to check for proper card matching by checking the pixel colours of the extracted cards.

Further tests could check the output by rendering the created pdf into an image with pdftoppm and then checking the card colours in specific spots there as well.

Please describe the problem the feature is supposed to solve.

Many card grids come without added bleed around the cards. In these cases the only option to not get ugly borders is currently to turn parts off the card itself into bleed (if the layout supports this).

Describe the solution you'd like

would it be possible to add an option of adding a background colour to each side of the fold (or frame around a card), for the cards that don't really have any bleed? Maybe by providing a HEX code?

• https://boardgamegeek.com/thread/3298313/article/44310129#44310129