Separate PDF constraints from hard-coded constraints about word-search-generator HOT 5 CLOSED

The max puzzle size was originally much larger, I only limited it because that was best for the pdf output. Any larger and the puzzle text becomes so small it's unreadable. So having two sets of limits would not be hard to implement, it would just be weird to explain the limit to a user when they have a 50x50 puzzle and wants to save it to a pdf.

As for the minimum size, the only issue with setting it to the length of the smallest word is what happens when someone gives 10 words all 3 characters long. You'd have a tiny puzzle with hardly any words at all. I picked 10 because it was a good size to handle a decent amount of words and makes finding words a little challenging for level 1 puzzles (was thinking about early-age school kids). It also fits well on a PDF sheet. At a size of 10, the current generator easily fits all 7 planets. So we would either need to have a hard minimum (like 10 or 7) or require the user to specify the size (like the script you reference does). I usually like to provide sensible defaults so the user doesn't have to supply so man y arguments just to get any output.

The generator could be changed to fit all seven planets in a 7x7 puzzle but yes it would slow generation down as it would have to generate lots of puzzles to find a variation where all words fit. Currently, it can easily fit 5 of the 7 planets in a 7x7 puzzle.

The script from the blog post actually failed to do the planets in a 7x7 grid in 10 attempts the first 7 times I ran it.

python other.py planets.txt 7 7
...
I failed to place all the words after 10 attempts.

The script from the blog post worked better on the list of elements, placing it on 5, and 7 tries when I tested it. The current generator was able to place 114 of the 118 elements in a puzzle of the same size.

All of that to say, I agree that more density would probably be a good thing. I can work on implementing the required changes this week to the config and handling the edge cases with cli, csv, and pdf output.

from word-search-generator.

I forgot I also only limit the puzzle size when using the setter. If you set the size at time of initialization you can make it whatever you want. I originally did this so I could test it but forgot about it. I could simply remove the max size check on the setter and just let argparse handle that on the cli.

from word-search-generator.

Good call about the minimum size. 7 seems like a reasonable hard-coded minimum (and I have no problems with leaving it at its current value of 10).

I think I should have time next week to give a more in-depth look at the implementation & changes.

from word-search-generator.

I completely forgot I built the PDF builder to be fluid so a puzzle sized to 50 works fine (see attached). The puzzle grid and all fonts are calculated based on puzzle size and word count. I'm about to commit an update with puzzle size min @ 5 and max @50. I also updated the max puzzle words to 100.

I'm not sure who wants to do a 50x50 puzzle with 100 words but hey it's there. I ran a test of 35 PDF all sized to 50x50 with 100 words PDF calculations for the wordlist and the key didn't break so I think it's safe.

test.pdf

from word-search-generator.

@duck57, marking this as done with the commit I made a few hours ago on PR #17.

from word-search-generator.