justinburdett / playtest Goto Github PK

So it's not hardcoded, and so it doesn't overwrite previous editions.

Now that we can generate the HTML version, it'd be sweet to print right from your browser.

Useful CSS for this:

@media print {
  /* Make each page have a page-break afterward */
  .page {
    page-break-after:always;
  }

  /* ... well, except for that last one.. no reason to print paper-airplane paper */
  .page:last-child {
    page-break-after:avoid;
  }

  /* hide the printer's header & footer (in Chrome at least..) */
  @page { margin: 0; }
  body { margin: 1.6cm; }
}

However, including this CSS throws off the wkhtmltopdf conversion (and makes a much larger margin around each page). Can't deal with that any further right now.

It's bad.

Our non-table layout no longer fill the full space and doesn't seem to comply with page-break-before. I don't want to switch back to tables but I think we are currently losing a lot of the utility we had.

I think we have some files left over from various iterations that don't need to be there.

From livrem on reddit:

Registration marks along the edges are very useful when cutting as well, and I think you can make that easily by just adding empty table cells with some CSS styling around the edges of the actual cards.

The readme needs to be updated like woah

From livrem on reddit
http://www.reddit.com/r/tabletopgamedesign/comments/1r3678/playtest_an_open_source_script_i_made_that_makes/cdjv21w

I think it would be very powerful if you just picked all values given for each card and created a div for it, with the name of the value as id. Then the user can create whatever card layout possible just by setting the CSS for that id, and would not be limited to some small hardcoded HTML template. This would probably result in even less code than your current solution AND be more useful, so big win (except for rewriting 5 lines of code).

It could be helpful to make the output static HTML with print CSS applied as well. Possibly an option?

Enhancement for down the road...

Add the ability to incorporate small images into the cards. The image to use could be included as a line in the YAML ("/path/to/image.jpg") and the script could use one of the many image processing libs to ensure it's the correct dimensions. Incorporating into the HTML doc might require some tweaking -- perhaps we could export it as an MHTML archive or something?

Incorporating into the PDF would be easy enough -- there are image embedding functions in Prawn that I saw when working on the last PR last night.

"Convention":
Card data would have a set list of acceptable attributes (whitelisted) that would be implemented in the layout. This would allow for a much more precise and slick looking layout in the export (both formats). The downside is that we would be constraining ourselves to a smaller creative space, and the script would require modification to add additional data properties.

"Configuration":
This is the approach currently adopted (mostly) -- users can put whatever the heck they want in the YML file, the only fields sort of required are the name (defaults to "unknown" I think) and quantity (defaults to 1). Everything else gets dumped into a Key:Value pairing in the textbox. This affords maximum flexibility in fields, but makes the cards a little less pretty.

Thoughts? Should there be some additional fields that are canonized into the template?

For example, if we were handling MTG cards:

• mana_cost
• flavor text
• description
• power_toughness
• card_type
• color

Obviously those are a little specific. More generally:

• cost
• description
• type

might be adequate to cover most cards? These would not be required fields, they would just have pre-figured handlers for dealing with them (ie. cost always goes in the same place, type, description as well).