squib 0.8.0 → 0.9.0

Sign up to get free protection for your applications and to get access to all the features.
Files changed (140) hide show
  1. checksums.yaml +4 -4
  2. data/.gitmodules +14 -0
  3. data/.travis.yml +4 -0
  4. data/CHANGELOG.md +201 -175
  5. data/Gemfile +2 -4
  6. data/README.md +650 -645
  7. data/RELEASE TODO.md +18 -18
  8. data/Rakefile +106 -99
  9. data/appveyor.yml +29 -0
  10. data/lib/squib.rb +32 -32
  11. data/lib/squib/api/background.rb +20 -20
  12. data/lib/squib/api/data.rb +131 -131
  13. data/lib/squib/api/image.rb +108 -90
  14. data/lib/squib/api/save.rb +151 -149
  15. data/lib/squib/api/settings.rb +35 -35
  16. data/lib/squib/api/shapes.rb +255 -230
  17. data/lib/squib/api/text.rb +65 -65
  18. data/lib/squib/api/text_embed.rb +96 -96
  19. data/lib/squib/args/arg_loader.rb +138 -138
  20. data/lib/squib/args/box.rb +54 -54
  21. data/lib/squib/args/card_range.rb +32 -32
  22. data/lib/squib/args/color_validator.rb +11 -11
  23. data/lib/squib/args/coords.rb +32 -32
  24. data/lib/squib/args/dir_validator.rb +16 -16
  25. data/lib/squib/args/draw.rb +92 -92
  26. data/lib/squib/args/embed_adjust.rb +25 -25
  27. data/lib/squib/args/embed_key.rb +17 -17
  28. data/lib/squib/args/hand_special.rb +37 -37
  29. data/lib/squib/args/import.rb +39 -39
  30. data/lib/squib/args/input_file.rb +37 -37
  31. data/lib/squib/args/paint.rb +43 -43
  32. data/lib/squib/args/paragraph.rb +116 -115
  33. data/lib/squib/args/save_batch.rb +63 -60
  34. data/lib/squib/args/scale_box.rb +53 -53
  35. data/lib/squib/args/sheet.rb +72 -72
  36. data/lib/squib/args/showcase_special.rb +38 -38
  37. data/lib/squib/args/svg_special.rb +37 -37
  38. data/lib/squib/args/transform.rb +60 -24
  39. data/lib/squib/args/typographer.rb +117 -117
  40. data/lib/squib/card.rb +66 -67
  41. data/lib/squib/conf.rb +131 -117
  42. data/lib/squib/constants.rb +12 -178
  43. data/lib/squib/deck.rb +113 -113
  44. data/lib/squib/graphics/cairo_context_wrapper.rb +113 -99
  45. data/lib/squib/graphics/gradient_regex.rb +46 -46
  46. data/lib/squib/graphics/hand.rb +42 -42
  47. data/lib/squib/graphics/image.rb +103 -76
  48. data/lib/squib/graphics/save_doc.rb +103 -103
  49. data/lib/squib/graphics/save_images.rb +39 -33
  50. data/lib/squib/graphics/shapes.rb +135 -119
  51. data/lib/squib/graphics/showcase.rb +85 -85
  52. data/lib/squib/graphics/text.rb +176 -176
  53. data/lib/squib/layout_parser.rb +91 -91
  54. data/lib/squib/layouts/economy.yml +85 -85
  55. data/lib/squib/layouts/fantasy.yml +101 -101
  56. data/lib/squib/layouts/hand.yml +62 -62
  57. data/lib/squib/layouts/playing-card.yml +35 -35
  58. data/lib/squib/layouts/tuck_box.yml +45 -45
  59. data/lib/squib/project_template/IDEAS.md +22 -0
  60. data/lib/squib/project_template/PLAYTESTING.md +26 -0
  61. data/lib/squib/project_template/RULES.md +21 -0
  62. data/lib/squib/project_template/config.yml +49 -45
  63. data/lib/squib/sample_helpers.rb +34 -0
  64. data/lib/squib/version.rb +10 -10
  65. data/samples/autoscale_font/_autoscale_font.rb +29 -0
  66. data/samples/color_shortcuts.rb +6 -6
  67. data/samples/csv_import.rb +26 -26
  68. data/samples/custom-config.yml +5 -5
  69. data/samples/custom_config.rb +18 -18
  70. data/samples/draw_shapes.rb +48 -45
  71. data/samples/embed_text.rb +88 -88
  72. data/samples/excel.rb +55 -55
  73. data/samples/hand.rb +24 -24
  74. data/samples/images/_images.rb +104 -0
  75. data/samples/intro/01_hello.rb +9 -0
  76. data/samples/intro/02_options.rb +15 -0
  77. data/samples/intro/03_layout.rb +12 -0
  78. data/samples/intro/04_arrays.rb +16 -0
  79. data/samples/intro/05_excel.rb +15 -0
  80. data/samples/layouts.rb +62 -62
  81. data/samples/layouts_builtin.rb +51 -51
  82. data/samples/load_images.rb +99 -78
  83. data/samples/load_images_config.yml +1 -0
  84. data/samples/quantity_explosion.csv +2 -2
  85. data/samples/ranges.rb +64 -64
  86. data/samples/sample.csv +2 -2
  87. data/samples/saves.rb +9 -1
  88. data/samples/sprites.png +0 -0
  89. data/samples/text/_text.rb +46 -0
  90. data/samples/text_options.rb +102 -102
  91. data/spec/api/api_data_spec.rb +117 -117
  92. data/spec/api/api_settings_spec.rb +37 -37
  93. data/spec/args/box_spec.rb +127 -127
  94. data/spec/args/draw_spec.rb +101 -95
  95. data/spec/args/embed_key_spec.rb +13 -13
  96. data/spec/args/input_file_spec.rb +21 -21
  97. data/spec/args/paint_spec.rb +21 -21
  98. data/spec/args/paragraph_spec.rb +152 -152
  99. data/spec/args/range_spec.rb +40 -40
  100. data/spec/args/save_batch_spec.rb +51 -51
  101. data/spec/args/scale_box_spec.rb +71 -71
  102. data/spec/args/sheet_spec.rb +58 -58
  103. data/spec/args/showcase_special_spec.rb +15 -15
  104. data/spec/args/transform_spec.rb +25 -0
  105. data/spec/card_spec.rb +11 -0
  106. data/spec/conf_spec.rb +13 -3
  107. data/spec/data/conf/unrecognized.yml +4 -0
  108. data/spec/data/csv/qty.csv +2 -2
  109. data/spec/data/csv/qty_named.csv +2 -2
  110. data/spec/data/csv/with_spaces.csv +2 -2
  111. data/spec/data/samples/autoscale_font.rb.txt +84 -84
  112. data/spec/data/samples/basic.rb.txt +227 -209
  113. data/spec/data/samples/config_text_markup.rb.txt +72 -72
  114. data/spec/data/samples/csv_import.rb.txt +213 -213
  115. data/spec/data/samples/custom_config.rb.txt +57 -48
  116. data/spec/data/samples/draw_shapes.rb.txt +555 -3
  117. data/spec/data/samples/embed_text.rb.txt +283 -283
  118. data/spec/data/samples/excel.rb.txt +661 -661
  119. data/spec/data/samples/gradients.rb.txt +77 -79
  120. data/spec/data/samples/hand.rb.txt +538 -538
  121. data/spec/data/samples/hello_world.rb.txt +36 -36
  122. data/spec/data/samples/load_images.rb.txt +170 -0
  123. data/spec/data/samples/portrait-landscape.rb.txt +51 -49
  124. data/spec/data/samples/ranges.rb.txt +472 -460
  125. data/spec/data/samples/saves.rb.txt +810 -801
  126. data/spec/data/samples/showcase.rb.txt +5926 -5910
  127. data/spec/data/samples/text_options.rb.txt +1125 -1125
  128. data/spec/data/samples/tgc_proofs.rb.txt +95 -81
  129. data/spec/graphics/cairo_context_wrapper_spec.rb +104 -84
  130. data/spec/graphics/graphics_save_doc_spec.rb +67 -67
  131. data/spec/samples/diff-with-css.example.html +39 -0
  132. data/spec/samples/expected/load_images_00.png +0 -0
  133. data/spec/samples/expected/shape_00.png +0 -0
  134. data/spec/samples/run_samples_spec.rb +17 -0
  135. data/spec/samples/samples_regression_spec.rb +72 -82
  136. data/spec/spec_helper.rb +9 -1
  137. data/squib.gemspec +49 -48
  138. data/squib.sublime-project +42 -42
  139. metadata +94 -48
  140. data/spec/graphics/graphics_images_spec.rb +0 -94
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA1:
3
- metadata.gz: ebe09b3a47c609d39587cd6ca28697dda3f7799b
4
- data.tar.gz: d92fedcde11597ef02277afd1d4cace28a08537a
3
+ metadata.gz: adaeb3ca2f3b20094dacf000a6e584966fce017a
4
+ data.tar.gz: f1def218de468cbcb268253d8d6b60ccb74b4dec
5
5
  SHA512:
6
- metadata.gz: eb307fcf715711fca60e5fdab698c39a324aec249a5d33c65317ff0e52799302abf26bb00d19e0794d5bbb190a1a01b21c600b99ac0bccec6b992753fda88846
7
- data.tar.gz: 5ec28990c090b049545e58e1c97488aeab73c64537076b95e207638dcf8362ee66cbeb4c7384a368b94c5abf1263f777e64243607f037ab954586e49d3e81d76
6
+ metadata.gz: c66f623177f31a1d51974fa9e51ccc53f90186a98de5500235d297d0bab120a187e251a7f029a2b7cc018df276ca07022c9846c85b3612f10c929d8cef2ae06b
7
+ data.tar.gz: 4367598eeb9c8e77b79254194308d36e135f992ac65aa8d46e1f001660e408266fb4a1ae451b4e404bba2c1aeed2a1b57267b8a6ca6323d77a55a9832ce36641
@@ -0,0 +1,14 @@
1
+ [submodule "samples/intro"]
2
+ path = samples/intro
3
+ url = https://gist.github.com/5026392a419124312cb7.git
4
+
5
+ [submodule "samples/images"]
6
+ path = samples/images
7
+ url = https://gist.github.com/00ba7eb0aa1d82140503.git
8
+
9
+ [submodule "samples/text"]
10
+ path = samples/text
11
+ url = https://gist.github.com/52d7b8e332194946bc69.git
12
+ [submodule "samples/autoscale_font"]
13
+ path = samples/autoscale_font
14
+ url = https://gist.github.com/andymeneely/a4536fff0f3dc5d59c66
@@ -5,3 +5,7 @@ rvm:
5
5
  - 2.0
6
6
  - 2.1
7
7
  - 2.2
8
+ - 2.3
9
+ matrix:
10
+ allow_failures:
11
+ - rvm: 2.3
@@ -1,175 +1,201 @@
1
- # Squib CHANGELOG
2
- Squib follows [semantic versioning](http://semver.org).
3
-
4
- ## v0.8.0 / 2015-10-26
5
- Features
6
- * The `xlsx` and `csv` support quantity explosion! Just use the column name 'Qty' and put integers in your sheet and you'll produce copies of the entire row. See README and the csv sample for more info. (#78)
7
- * The `xlsx` and `csv` methods will now strip leading and trailing whitespace by default where applicable. This is now turned on by default, but can be turned off with `strip: false`. (#79)
8
- * The `xlsx` and `csv` methods will now yield to a block (if given) for each cell so you can do some extra processing if you like. See samples/excel.rb for an example. (#108)
9
- * Layout file for TheGameCrafter tuck boxes (#113). Thanks @alexgorski!
10
-
11
- Compatibility change:
12
- * Stripping leading and trailing whitespace of xlsx and csv values by default might change how your data gets parsed.
13
-
14
- Bugs fixes:
15
- * The `range` option everywhere doesn't fail on `[]` (#107)
16
-
17
- ## v0.7.0 / 2015-09-11
18
-
19
- Features
20
- * Added `cap` option to `line` and `curve` to define how ends of lines are drawn (#42)
21
- * Added `join` option to all drawing operations (e.g. `rect`, `star`, even outlines for `text`) to define how corners are drawn. (#42)
22
- * Added `dash` option to all drawing operations (e.g. `rect`, `star`, even outlines for `text`) so you can specify your own dash pattern. Just specify a string with space-separated numbers to specify the on-and-off alternating pattern (e.g. `dash: '2 2'` with a stroke width of `2` is evenly spaced dots). Supports unit conversion (e.g. `dash: '0.02in 0.02in'`) (#42)
23
- * Added an idiom to the `ranges.rb` sample for drawing a different number of images based on the column in a table (e.g. 2 arrows to indicate 2 actions). Based on question #90. There are probably even cleaner, Ruby-ish ways to do this too - pull requests are welcome.
24
- * The `text` method and several other methods will throw errors on invalid input. This means your scripts will be more likely to break if you provide bad input. Please report bugs if you thinkg this unfairly breaks your code.
25
- * The `text` embedding icon now allows singleton expansion, which means that you can have icons have different sizes on different cards. The sample `embed_text.rb` demonstrates this. (#54)
26
- * The `text` method will throw a warning when it needs to ellipsize text (i.e. too much text for a fixed-size text box). Can be turned off in `config.yml`. (#80)
27
- * Upgraded roo (Excel parsing) to 2.1.0. Macro-enabled Excel files can be parsed now (i.e. `xlsm`), although I've only mildly tested this. (cddea47ba56add286639e493d5cc0146245eca68)
28
- * New built-in layouts: `fantasy.yml` and `economy.yml`. Demonstrated in new sample `layouts_builtin.rb` (#97)
29
- * Added `:scale` shortcut to `width` and `height` options for `png` and `svg`. Allows you to set the width and the image will scale while keeping its aspect ratio. (e.g. `svg width: 500, height: :scale`) (#91)
30
- * Upgraded cairo dependency to 1.14.3, which silences some warnings on Macs and upgrades a lot of Windows dependencies.
31
- * Upgraded pango, librsvg dependencies to 3.0.0, which focused mainly on upgrading Windows dependencies.
32
-
33
- Compatibility:
34
- * All drawn shapes (e.g. circle, triangle, star) will now draw their stroke on top of the fill. This was not consistent before, and now it is (because Squib is more DRY about it!). This means that your `stroke_width` might render wider than before. If you want the other behavior, specify `stroke_strategy: :stroke_first`. Also applies to `text` when `stroke_width` is specified.
35
- * The `width` and `height` options for `text` have changed their defaults from `:native` to `:auto`. This is to differentiate them from `:native` widths that default elsewhere. Additionally, `width` and `height` for shapes now default to `:deck`, and get interpreted as the deck width and height. The `:native` options are interpreted for SVG and PNG images as their original values. The behavior is all the same, just with more specific names.
36
- * Removed `img_dir` from the `set` method. You can still set `img_dir` in the configuration file (e.g. `config.yml`). Added a deprecation error.
37
-
38
- Bugs:
39
- * Fixed a `Cairo::WriteError` on `save_sheet` (#56, PR #96 thank you @meltheadorable!)
40
- * Investigated a NoMemoryError on Macs. Solution: upgrade to Ruby 2.2. (#88)
41
-
42
- Chores:
43
- * Refactoring to make internal drawing code more DRY (#75, and much more). This is a big re-design that will help ease future features that involve manipulating arguments. Trust me. This was worth the wait and all the hard work.
44
- * Better testing and general flexibility around the `range` option.
45
-
46
- ## v0.6.0 / 2015-05-26
47
-
48
- Features:
49
- * Added `data` field to `svg` to allow for manipulating SVG XML data directly. Works nicely with my new `game_icons` [gem](https://github.com/andymeneely/game_icons) (#65)
50
- * Added `stroke_width` and `stroke_color` to the `text` method to outlines text. (#51)
51
- * Added `hand` method that draws cards around a circle. See hand.rb samples (#64)
52
- * Added an `ellipse` method to (you guessed it) draw ellipses. See the draw_shapes.rb sample (#66)
53
- * Added a `star` method to (you guessed it) draw stars. See the draw_shapes.rb sample (#72)
54
- * Added a `polygon` method to (you guessed it) draw polygons. See the draw_shapes.rb sample (#67)
55
- * Upgraded roo (Excel parsing) to 2.0.0. Nothing major for Squib users, just keeping up with the times.
56
-
57
- Bugs:
58
- * Text embed svg and png commands default to integer so the README example works (#73).
59
- * Fixed global text hinting (#63)
60
- * Fixed a broken promise about fill_color in `showcase` (#71)
61
-
62
- Compatbility:
63
- * rsvg2 and pango updated to v2.2.5. Squib follows 2.2.x of both of those. If you run `bundle` you will automatically be upgraded. They appear to be mostly bugfix releases.
64
- * dpi is currently removed from `config.yml` and is ONLY available in `Squib::Deck.new`. This may change in the future, however.
65
-
66
- Chores:
67
- * Massive internal redesigning of the way configuration options are parsed, stored, handled. No real changes are visible to the user, but this code will be more maintainable and open up the door for more flexible configuration options in the future.
68
- * Added `rake sanity` as a visual regression test to ensure the samples don't break
69
- * Lots of automated test refactoring
70
-
71
- Thanks to [pickfifteen](https://github.com/pickfifteen), and [Brian Cronin](http://www.boardgamegeek.com/user/MurphyIdiot) for the bug reports!
72
-
73
- ## v0.5.1 / 2015-04-13
74
-
75
- Bugs:
76
- * Fixed a PDF scaling issue, so now page width and height is properly calculated from DPI (#62)
77
-
78
- Thanks to [Brian Cronin](http://www.boardgamegeek.com/user/MurphyIdiot) for the bug report.
79
-
80
- ## v0.5.0 / 2015-04-13
81
- Features:
82
- * Embedding of SVGs and PNGs into text! See README, `text_options.rb`, and `embed_text.rb`, and API documentation. This was a finnicky feature, so feedback and bug reports are welcome. (#30)
83
- * Curves! We can now do Bezier curves. Documented, and added to the sample `draw_shapes.rb` (#37).
84
- * Smart Quotes! The `text` rule now has a `quotes: 'smart'` option where straight quotes get converted to curly quotes. Assumes UTF-8, or you can specify your own quote characters if you're not in UTF-8. (#50)
85
- * Font-level antialiasing is inherited from global antialiasing setting (workaround until we get a better solution for #59).
86
-
87
- Known issues
88
- * OSX Yosemite will show this warning: `<Error>: The function ‘CGFontGetGlyphPath’ is obsolete and will be removed in an upcoming update. Unfortunately, this application, or a library it uses, is using this obsolete function, and is thereby contributing to an overall degradation of system performance.` This warning will go away when the Ruby Cairo bindings upgrades from 1.14.1 to 1.14.2.
89
-
90
- Special thanks to [pickfifteen](https://github.com/pickfifteen) for testing, feedback, and pull requests!!
91
-
92
- ## v0.4.0 / 2015-04-28
93
-
94
- Features:
95
- * SVG backend support! You can now set the deck's back end to work with SVGs instead of images, making the resulting PDFs vectorized. (You can still save to PNGs too.) This was a big change for Squib, and it's got at least one known issue and probably a few more here and there. See discussion on the README for more details.
96
- * Added config option for antialiasing method. My benchmarks showed that 'best' is only 10% slower than 'fast' on extremely alias-intensive tasks, so 'best' is the Squib default now.
97
-
98
- Bugs:
99
- * Stray stroke on circles after text (#35)
100
- * Progress bar increment error (#34)
101
-
102
- Known issues
103
- * Masking SVGs onto an SVG backend will rasterize as an intermediate step. (#43)
104
- * Compatibility change: gradient coordinates for the `mask` option in `svg` and `png` commands are relative to the given x,y - NOT to card as it was before.
105
-
106
- ## v0.3.0 / 2015-02-02
107
-
108
- Features:
109
- * Masks! The `png` and `svg` commands can be used as if they are a mask, so you can color the icon with any color you like. Can be handy for switching to black-and-white, or for reusing the same image but different colors across cards.
110
- * Gradients! Can now specify linear or radial gradients anywhere you specify colors. See README and `samples/gradients.rb` for more details.
111
- * Number padding! `save_png` will now pad zeros on the filenames for friendlier sorting. You can also specify your own with `count_format` using the classical format string from Ruby's `Kernel::sprintf` (mostly just C-style format strings). Default: `'%02d'. The `prefix:` option is still there too.
112
- * Added unit conversion to `Squib::New` and `save_pdf`
113
- * Added arbitrary paper sizes to `save_pdf`
114
- * Added new sample table for color viewing constants in `samples/colors.rb`
115
-
116
- Special thanks to [Shalom Craimer](https://github.com/scraimer) for the idea and proof-of-concept on gradient and mask features!
117
-
118
- ## v0.2.0 / 2015-01-12
119
-
120
- Features:
121
- * Added `showcase` feature to create a fancy-looking 3D reflection to showcase your cards. Documented, tested, and added a sample for it.
122
- * Added a basic Rakefile, documented in README.
123
- * Some internal refactoring, better testing, and more documentation with layouts
124
-
125
- ## v0.1.0 / 2014-12-31
126
-
127
- Features:
128
- * Added `save_sheet` command that saves a range into PNG sheets, complete with trim, gap, margin, columns, and sometimes automagically computed rows. See samples/saves.rb.
129
- * Unit conversion! Now you can write "2in" and it will convert based on the current dpi. `save_pdf` not supported (yet).
130
- * `png` now supports resizing, but warns you about it since it's non-ideal. Documented in yard, tested.
131
- * Added sample `unicode.rb` to show lots of game-related unicode characters
132
-
133
- Chores:
134
- * More obsessive automated testing and continuous integration work.
135
-
136
- ## v0.0.6 / 2014-12-08
137
-
138
- Features:
139
- * Added a `csv` command that works just like `xslx`. Uses Ruby's CSV inside, with some extra checking and warnings.
140
- * Custom layouts now support loading & merging multiple Yaml files! Updated README, docs, and sample to document it.
141
- * Built-in layouts! Currently we support `hand.yml` and `playing-card.yml`. Documented in the `layouts.rb` sample.
142
- * `text` now returns the ink extent rectangle of the rendered text. Updated docs and sample to document it.
143
- * Samples now show that you can use text instead of symbols for things like `center`
144
-
145
- Chores:
146
- * Improved logging, and documentation on increasing logger verboseness
147
- * Better regression testing technique that tracks when a sample has changed.
148
- * Bumped version of Cairo to ~> 1.14
149
-
150
- ## v0.0.5 / 2014-11-03
151
- * Image rotation for png and svg via `angle`
152
- * New sample for demonstrating direct cairo access
153
- * README now includes a snazzy screencast of the Sublime snippets
154
- * Rotation of text works more conventionally now, and works with text hints
155
- * Better code styles thanks to RuboCop
156
- * Better unit testing, now with mocking!
157
- * Various version bumps: rspec, yard
158
-
159
- ## v0.0.4 / 2014-10-17
160
- * Added a font size override so you can vary the font size with the same style across strings more easily
161
- * Added text autoscale sample
162
- * Added `extends` to custom layouts, allowing ways to modify parent data instead of just overriding it.
163
- * Upgraded ruby-progressbar version
164
- * Added text rotation (thanks novalis!)
165
- * Fixed a mapping problem with triangles (thanks novalis!)
166
- * Fixed global hint togglability
167
-
168
- ## v0.0.3 / 2014-08-30
169
- * Redesigned the dynamic options system to make adding new commands much easier
170
- * Singleton expansion
171
- * Better documentation in README and throughout
172
- * Implemented Junk Land in this version
173
-
174
- ## v0.0.1-v0.0.2 / 2014-07-29
175
- * Primordial era - base functionality
1
+ # Squib CHANGELOG
2
+ Squib follows [semantic versioning](http://semver.org).
3
+
4
+ ## v0.9.0 / 2016-01-10
5
+
6
+ Features:
7
+ * Crop your PNGs and SVGs! This means you can work from spritesheets if you want. New options to `png` and `svg` are documented in the API docs and demonstrated in the `load_images.rb` sample. (#11)
8
+ * Flip your PNGs and SVGs! Set `flip_horizontal: true` or `flip_vertical: true` (or both!) to flip the image about it's center. (#11)
9
+ * Added a `grid` shape that fills the whole card with a grid of your choosing. (#68)
10
+ * Added `warn_png_scale` configuration option to suppress the PNG scale warning. Also: warning only occurs on upscale, not on downscaling (#121)
11
+ * `save_png` now supports `trim` and `trim_radius`, which means you can now render your cards individually and bleedlessly! (#122)
12
+
13
+ Bug fixes:
14
+ * Radial Gradients when using a Mask does not work as anticipated (#127)
15
+
16
+ Chores:
17
+ * Ripped out a lot of old constants used from the old way we handled arguments. Yay negative churn!
18
+ * Emit a warning when a `config.yml` option is not recognized
19
+ * Upgrade roo (xlsx parser) to latest 2.3 version. Nothing exciting for us in this release.
20
+ * Force upgrade of nokogiri to latest 1.6.7 version. This should fix the Windows+Ruby2.2 problem.
21
+
22
+ Docs:
23
+ * [Squib's Wiki](https://github.com/andymeneely/squib/wiki) has started! We've begun the long process of developing more longform types of documentation, as well as organizing our documentation around workflows and recipes instead of features. Go check out and feel free to contribute. Help make the mega README be a relic of the past!
24
+ * Added new files to the project template for `squib new`: `IDEAS.md`, `RULES.md`, and `PLAYTESTING.md`
25
+ * Wrote up new samples that are more web-friendly where you see the output right next to the code on GitHub gist: [images](https://gist.github.com/andymeneely/00ba7eb0aa1d82140503/514af49430797daf7a69c31118b6056dc4abaf20), [text](https://gist.github.com/andymeneely/52d7b8e332194946bc69/d1ebe078102b1eb6631ac9b1228a588395dc4bb5), [intro](https://gist.github.com/andymeneely/5026392a419124312cb7/fef084df3dbdfbdb749f418994e2b77124e49418)
26
+
27
+ Community:
28
+ * Beta testers needed!! Want to test pre-release of Squib? Join the mailing list for announcements. Go ahead and join our Google Group: https://groups.google.com/forum/#!forum/squib-testers
29
+
30
+ ## v0.8.0 / 2015-10-26
31
+ Features
32
+ * The `xlsx` and `csv` support quantity explosion! Just use the column name 'Qty' and put integers in your sheet and you'll produce copies of the entire row. See README and the csv sample for more info. (#78)
33
+ * The `xlsx` and `csv` methods will now strip leading and trailing whitespace by default where applicable. This is now turned on by default, but can be turned off with `strip: false`. (#79)
34
+ * The `xlsx` and `csv` methods will now yield to a block (if given) for each cell so you can do some extra processing if you like. See samples/excel.rb for an example. (#108)
35
+ * Layout file for TheGameCrafter tuck boxes (#113). Thanks @alexgorski!
36
+
37
+ Compatibility change:
38
+ * Stripping leading and trailing whitespace of xlsx and csv values by default might change how your data gets parsed.
39
+
40
+ Bugs fixes:
41
+ * The `range` option everywhere doesn't fail on `[]` (#107)
42
+
43
+ ## v0.7.0 / 2015-09-11
44
+
45
+ Features
46
+ * Added `cap` option to `line` and `curve` to define how ends of lines are drawn (#42)
47
+ * Added `join` option to all drawing operations (e.g. `rect`, `star`, even outlines for `text`) to define how corners are drawn. (#42)
48
+ * Added `dash` option to all drawing operations (e.g. `rect`, `star`, even outlines for `text`) so you can specify your own dash pattern. Just specify a string with space-separated numbers to specify the on-and-off alternating pattern (e.g. `dash: '2 2'` with a stroke width of `2` is evenly spaced dots). Supports unit conversion (e.g. `dash: '0.02in 0.02in'`) (#42)
49
+ * Added an idiom to the `ranges.rb` sample for drawing a different number of images based on the column in a table (e.g. 2 arrows to indicate 2 actions). Based on question #90. There are probably even cleaner, Ruby-ish ways to do this too - pull requests are welcome.
50
+ * The `text` method and several other methods will throw errors on invalid input. This means your scripts will be more likely to break if you provide bad input. Please report bugs if you thinkg this unfairly breaks your code.
51
+ * The `text` embedding icon now allows singleton expansion, which means that you can have icons have different sizes on different cards. The sample `embed_text.rb` demonstrates this. (#54)
52
+ * The `text` method will throw a warning when it needs to ellipsize text (i.e. too much text for a fixed-size text box). Can be turned off in `config.yml`. (#80)
53
+ * Upgraded roo (Excel parsing) to 2.1.0. Macro-enabled Excel files can be parsed now (i.e. `xlsm`), although I've only mildly tested this. (cddea47ba56add286639e493d5cc0146245eca68)
54
+ * New built-in layouts: `fantasy.yml` and `economy.yml`. Demonstrated in new sample `layouts_builtin.rb` (#97)
55
+ * Added `:scale` shortcut to `width` and `height` options for `png` and `svg`. Allows you to set the width and the image will scale while keeping its aspect ratio. (e.g. `svg width: 500, height: :scale`) (#91)
56
+ * Upgraded cairo dependency to 1.14.3, which silences some warnings on Macs and upgrades a lot of Windows dependencies.
57
+ * Upgraded pango, librsvg dependencies to 3.0.0, which focused mainly on upgrading Windows dependencies.
58
+
59
+ Compatibility:
60
+ * All drawn shapes (e.g. circle, triangle, star) will now draw their stroke on top of the fill. This was not consistent before, and now it is (because Squib is more DRY about it!). This means that your `stroke_width` might render wider than before. If you want the other behavior, specify `stroke_strategy: :stroke_first`. Also applies to `text` when `stroke_width` is specified.
61
+ * The `width` and `height` options for `text` have changed their defaults from `:native` to `:auto`. This is to differentiate them from `:native` widths that default elsewhere. Additionally, `width` and `height` for shapes now default to `:deck`, and get interpreted as the deck width and height. The `:native` options are interpreted for SVG and PNG images as their original values. The behavior is all the same, just with more specific names.
62
+ * Removed `img_dir` from the `set` method. You can still set `img_dir` in the configuration file (e.g. `config.yml`). Added a deprecation error.
63
+
64
+ Bugs:
65
+ * Fixed a `Cairo::WriteError` on `save_sheet` (#56, PR #96 thank you @meltheadorable!)
66
+ * Investigated a NoMemoryError on Macs. Solution: upgrade to Ruby 2.2. (#88)
67
+
68
+ Chores:
69
+ * Refactoring to make internal drawing code more DRY (#75, and much more). This is a big re-design that will help ease future features that involve manipulating arguments. Trust me. This was worth the wait and all the hard work.
70
+ * Better testing and general flexibility around the `range` option.
71
+
72
+ ## v0.6.0 / 2015-05-26
73
+
74
+ Features:
75
+ * Added `data` field to `svg` to allow for manipulating SVG XML data directly. Works nicely with my new `game_icons` [gem](https://github.com/andymeneely/game_icons) (#65)
76
+ * Added `stroke_width` and `stroke_color` to the `text` method to outlines text. (#51)
77
+ * Added `hand` method that draws cards around a circle. See hand.rb samples (#64)
78
+ * Added an `ellipse` method to (you guessed it) draw ellipses. See the draw_shapes.rb sample (#66)
79
+ * Added a `star` method to (you guessed it) draw stars. See the draw_shapes.rb sample (#72)
80
+ * Added a `polygon` method to (you guessed it) draw polygons. See the draw_shapes.rb sample (#67)
81
+ * Upgraded roo (Excel parsing) to 2.0.0. Nothing major for Squib users, just keeping up with the times.
82
+
83
+ Bugs:
84
+ * Text embed svg and png commands default to integer so the README example works (#73).
85
+ * Fixed global text hinting (#63)
86
+ * Fixed a broken promise about fill_color in `showcase` (#71)
87
+
88
+ Compatbility:
89
+ * rsvg2 and pango updated to v2.2.5. Squib follows 2.2.x of both of those. If you run `bundle` you will automatically be upgraded. They appear to be mostly bugfix releases.
90
+ * dpi is currently removed from `config.yml` and is ONLY available in `Squib::Deck.new`. This may change in the future, however.
91
+
92
+ Chores:
93
+ * Massive internal redesigning of the way configuration options are parsed, stored, handled. No real changes are visible to the user, but this code will be more maintainable and open up the door for more flexible configuration options in the future.
94
+ * Added `rake sanity` as a visual regression test to ensure the samples don't break
95
+ * Lots of automated test refactoring
96
+
97
+ Thanks to [pickfifteen](https://github.com/pickfifteen), and [Brian Cronin](http://www.boardgamegeek.com/user/MurphyIdiot) for the bug reports!
98
+
99
+ ## v0.5.1 / 2015-04-13
100
+
101
+ Bugs:
102
+ * Fixed a PDF scaling issue, so now page width and height is properly calculated from DPI (#62)
103
+
104
+ Thanks to [Brian Cronin](http://www.boardgamegeek.com/user/MurphyIdiot) for the bug report.
105
+
106
+ ## v0.5.0 / 2015-04-13
107
+ Features:
108
+ * Embedding of SVGs and PNGs into text! See README, `text_options.rb`, and `embed_text.rb`, and API documentation. This was a finnicky feature, so feedback and bug reports are welcome. (#30)
109
+ * Curves! We can now do Bezier curves. Documented, and added to the sample `draw_shapes.rb` (#37).
110
+ * Smart Quotes! The `text` rule now has a `quotes: 'smart'` option where straight quotes get converted to curly quotes. Assumes UTF-8, or you can specify your own quote characters if you're not in UTF-8. (#50)
111
+ * Font-level antialiasing is inherited from global antialiasing setting (workaround until we get a better solution for #59).
112
+
113
+ Known issues
114
+ * OSX Yosemite will show this warning: `<Error>: The function ‘CGFontGetGlyphPath’ is obsolete and will be removed in an upcoming update. Unfortunately, this application, or a library it uses, is using this obsolete function, and is thereby contributing to an overall degradation of system performance.` This warning will go away when the Ruby Cairo bindings upgrades from 1.14.1 to 1.14.2.
115
+
116
+ Special thanks to [pickfifteen](https://github.com/pickfifteen) for testing, feedback, and pull requests!!
117
+
118
+ ## v0.4.0 / 2015-04-28
119
+
120
+ Features:
121
+ * SVG backend support! You can now set the deck's back end to work with SVGs instead of images, making the resulting PDFs vectorized. (You can still save to PNGs too.) This was a big change for Squib, and it's got at least one known issue and probably a few more here and there. See discussion on the README for more details.
122
+ * Added config option for antialiasing method. My benchmarks showed that 'best' is only 10% slower than 'fast' on extremely alias-intensive tasks, so 'best' is the Squib default now.
123
+
124
+ Bugs:
125
+ * Stray stroke on circles after text (#35)
126
+ * Progress bar increment error (#34)
127
+
128
+ Known issues
129
+ * Masking SVGs onto an SVG backend will rasterize as an intermediate step. (#43)
130
+ * Compatibility change: gradient coordinates for the `mask` option in `svg` and `png` commands are relative to the given x,y - NOT to card as it was before.
131
+
132
+ ## v0.3.0 / 2015-02-02
133
+
134
+ Features:
135
+ * Masks! The `png` and `svg` commands can be used as if they are a mask, so you can color the icon with any color you like. Can be handy for switching to black-and-white, or for reusing the same image but different colors across cards.
136
+ * Gradients! Can now specify linear or radial gradients anywhere you specify colors. See README and `samples/gradients.rb` for more details.
137
+ * Number padding! `save_png` will now pad zeros on the filenames for friendlier sorting. You can also specify your own with `count_format` using the classical format string from Ruby's `Kernel::sprintf` (mostly just C-style format strings). Default: `'%02d'. The `prefix:` option is still there too.
138
+ * Added unit conversion to `Squib::New` and `save_pdf`
139
+ * Added arbitrary paper sizes to `save_pdf`
140
+ * Added new sample table for color viewing constants in `samples/colors.rb`
141
+
142
+ Special thanks to [Shalom Craimer](https://github.com/scraimer) for the idea and proof-of-concept on gradient and mask features!
143
+
144
+ ## v0.2.0 / 2015-01-12
145
+
146
+ Features:
147
+ * Added `showcase` feature to create a fancy-looking 3D reflection to showcase your cards. Documented, tested, and added a sample for it.
148
+ * Added a basic Rakefile, documented in README.
149
+ * Some internal refactoring, better testing, and more documentation with layouts
150
+
151
+ ## v0.1.0 / 2014-12-31
152
+
153
+ Features:
154
+ * Added `save_sheet` command that saves a range into PNG sheets, complete with trim, gap, margin, columns, and sometimes automagically computed rows. See samples/saves.rb.
155
+ * Unit conversion! Now you can write "2in" and it will convert based on the current dpi. `save_pdf` not supported (yet).
156
+ * `png` now supports resizing, but warns you about it since it's non-ideal. Documented in yard, tested.
157
+ * Added sample `unicode.rb` to show lots of game-related unicode characters
158
+
159
+ Chores:
160
+ * More obsessive automated testing and continuous integration work.
161
+
162
+ ## v0.0.6 / 2014-12-08
163
+
164
+ Features:
165
+ * Added a `csv` command that works just like `xslx`. Uses Ruby's CSV inside, with some extra checking and warnings.
166
+ * Custom layouts now support loading & merging multiple Yaml files! Updated README, docs, and sample to document it.
167
+ * Built-in layouts! Currently we support `hand.yml` and `playing-card.yml`. Documented in the `layouts.rb` sample.
168
+ * `text` now returns the ink extent rectangle of the rendered text. Updated docs and sample to document it.
169
+ * Samples now show that you can use text instead of symbols for things like `center`
170
+
171
+ Chores:
172
+ * Improved logging, and documentation on increasing logger verboseness
173
+ * Better regression testing technique that tracks when a sample has changed.
174
+ * Bumped version of Cairo to ~> 1.14
175
+
176
+ ## v0.0.5 / 2014-11-03
177
+ * Image rotation for png and svg via `angle`
178
+ * New sample for demonstrating direct cairo access
179
+ * README now includes a snazzy screencast of the Sublime snippets
180
+ * Rotation of text works more conventionally now, and works with text hints
181
+ * Better code styles thanks to RuboCop
182
+ * Better unit testing, now with mocking!
183
+ * Various version bumps: rspec, yard
184
+
185
+ ## v0.0.4 / 2014-10-17
186
+ * Added a font size override so you can vary the font size with the same style across strings more easily
187
+ * Added text autoscale sample
188
+ * Added `extends` to custom layouts, allowing ways to modify parent data instead of just overriding it.
189
+ * Upgraded ruby-progressbar version
190
+ * Added text rotation (thanks novalis!)
191
+ * Fixed a mapping problem with triangles (thanks novalis!)
192
+ * Fixed global hint togglability
193
+
194
+ ## v0.0.3 / 2014-08-30
195
+ * Redesigned the dynamic options system to make adding new commands much easier
196
+ * Singleton expansion
197
+ * Better documentation in README and throughout
198
+ * Implemented Junk Land in this version
199
+
200
+ ## v0.0.1-v0.0.2 / 2014-07-29
201
+ * Primordial era - base functionality
data/Gemfile CHANGED
@@ -1,4 +1,2 @@
1
- source 'https://rubygems.org'
2
- gemspec
3
-
4
- gem 'yard', :git => 'git://github.com/lsegal/yard', :branch => "master"
1
+ source 'https://rubygems.org'
2
+ gemspec
data/README.md CHANGED
@@ -1,645 +1,650 @@
1
- # Squib [![Gem Version](https://badge.fury.io/rb/squib.svg)](https://rubygems.org/gems/squib) [![Build Status](https://secure.travis-ci.org/andymeneely/squib.svg?branch=master)](https://travis-ci.org/andymeneely/squib) [![Dependency Status](https://gemnasium.com/andymeneely/squib.svg)](https://gemnasium.com/andymeneely/squib) [![Coverage Status](https://img.shields.io/coveralls/andymeneely/squib.svg)](https://coveralls.io/r/andymeneely/squib) [![Inline docs](http://inch-ci.org/github/andymeneely/squib.png?branch=master)](http://inch-ci.org/github/andymeneely/squib)
2
- Squib is a Ruby [DSL](http://en.wikipedia.org/wiki/Domain-specific_language) for prototyping card and board games. Write a little bit of Ruby, define your deck's stats, then compile your game into a series of images ready for print-and-play or even print-on-demand. Squib is very data-driven and built on the principle of Don't Repeat Yourself. Think of it like [nanDeck](http://www.nand.it/nandeck/) done "the Ruby way". Squib supports:
3
-
4
- * A concise set of rules for laying out your cards
5
- * Loading PNGs and SVGs
6
- * Complex text rendering using [Pango](http://www.pango.org/)
7
- * Reading `xlsx` and `csv` files
8
- * Rendering to PNGs, PDFs, and SVGs (sheets or individual files)
9
- * Flexible, data-driven layouts in Yaml
10
- * Basic shape drawing, blending operators, gradients, etc.
11
- * Unit conversion
12
- * The full power of Ruby!
13
-
14
- Squib is based on the [Cairo](http://cairographics.org/) graphics rendering engine, the library of choice for WebKit, Gecko, Inkscape and many, many others.
15
-
16
- Check this out.
17
-
18
- ```ruby
19
- require 'squib'
20
-
21
- Squib::Deck.new(cards: 2) do
22
- text str: %w(Hello World!)
23
- save_png
24
- end
25
- ```
26
-
27
- We just created a 2-card deck with "Hello" on the first card, and "World" on the second, and saved them out to PNGs.
28
-
29
- ## Installation
30
-
31
- Squib requires Ruby 2.0 or later.
32
-
33
- Install it yourself with:
34
-
35
- $ gem install squib
36
-
37
- If you're using Bundler, add this line to your application's Gemfile:
38
-
39
- gem 'squib'
40
-
41
- And then execute:
42
-
43
- $ bundle
44
-
45
- Note: Squib has some native dependencies, such as [Cairo](https://github.com/rcairo/rcairo), [Pango](http://ruby-gnome2.sourceforge.jp/hiki.cgi?Pango%3A%3ALayout), and [Nokogiri](http://nokogiri.org/), which may require compiling C code to install. This is usually not painful at all, and is automated through Bundler/RubyGems, but can cause headaches on some setups.
46
- * Windows: I recommend using the *non-64 bit* RubyInstaller at http://rubyinstaller.org. Some installations will also need DevKit. Currently, Ruby 2.2 on Windows conflicts with one of Squib's dependencies called Nokogiri (read the WTF-y issue here: https://github.com/sparklemotion/nokogiri/issues/1256) UPDATE: their pre-releases have fixed this exact issue - just install nokogiri-1.6.7.rc3-x64-mingw32 (or higher). Or, as a last resort, use 2.1 or 2.0 for Windows users.
47
- * Mac: I recommend using [rvm](https://rvm.io). Some users have reported that Ruby 2.1 will not work with Mac OSX 10.10.4 (#88) - Ruby 2.0 and 2.2 are confirmed to work however (this is an rcairo issue, not a Squib issue).
48
- * Cywgin is not supported, but could theoretically work with extra installation steps. See [this thread](http://boardgamegeek.com/article/18508113#18508113). Contributions in this area are welcome.
49
- * Linux. No known installation issues. Happy installing!
50
-
51
- ## Getting Started
52
-
53
- After installing Squib, you can create a project and run your first build like this:
54
-
55
- ```sh
56
- $ squib new my-cool-game
57
- $ cd my-cool-game
58
- $ ruby deck.rb
59
- ```
60
-
61
- The `squib new` command will generate files and folders like this:
62
-
63
- ```
64
- _output/gitkeep.txt
65
- .gitignore
66
- ABOUT.md
67
- config.yml
68
- deck.rb
69
- Gemfile
70
- layout.yml
71
- PNP NOTES.md
72
- ```
73
-
74
- The central file here is `deck.rb`. Here's a [basic example](https://github.com/andymeneely/squib/tree/master/samples/basic.rb) of a deck to work from:
75
-
76
- {include:file:samples/basic.rb basic.rb}
77
-
78
- About the other files:
79
- * `Gemfile` is for adding in other gems if you are using `bundler`
80
- * `config.yml` is a skeleton config file with various options commented out. See {file:README.md#Configuration_File Configuration File}.
81
- * `layout.yml` is a skeleton layout file if you want to use it. See {file:README.md#Custom_Layouts Custom Layouts}.
82
- * `_output` is the directory where your built files will go. Can easily be changed, of course.
83
- * `.gitignore` and `gitkeep.txt` are for if you are using Git. See {file:README.md#Source_control Source control}. (Feel free to remove these if you are not using Git.)
84
- * `ABOUT.md` and `PHP NOTES.md` are Markdown files for posting. Not used by Squib, but there by convention.
85
- * `Rakefile` is a basic build file. Not required but handy - see {file:README.md#Rakefile Rakefile}
86
-
87
- # Learning Squib
88
-
89
- In addition to this README, be sure to also check out the following resources for more details:
90
-
91
- * The `samples` directory in the [source repository](https://github.com/andymeneely/squib) has lots of examples.
92
- * [Iconoclast](https://github.com/andymeneely/iconoclast) is a basic set collection game I'm developing from scratch with Squib. Be sure to read the [commit history](https://github.com/andymeneely/iconoclast/commits/master) to see how the game has developed from scratch.
93
- * [Junk Land](https://github.com/andymeneely/junk-land) is my own creation that's uses Squib for full-color rendering, and makes use of Ruby in a lot of interesting ways.
94
-
95
- ## Viewing this README
96
-
97
- The best place to read this documentation is on [our website](http://andymeneely.github.io/squib/doc). Be sure to check out the method-by-method documentation, particularly for the [Deck](Squib/Deck.html) class.
98
-
99
- If you want to view it offline, you can do the following
100
-
101
- ```sh
102
- $ gem install yard
103
- $ yard server --gems
104
- ```
105
- Then go to [http://localhost:8808/docs/squib/file/README.md](http://localhost:8808/docs/squib/file/README.md)
106
-
107
- If you're viewing this on Github, you might see some confusing tags like `{include:file:...}` - these are directives for YARD to show the embedded examples. Github doesn't render those and you might find them helpful.
108
-
109
- Also, RubyDoc.info linked from RubyGems appears to be perpetually broken and doesn't support `{include:file...}` directive properly, so the embedded samples will also not show up there, either.
110
-
111
- ## Squib Decks and Cards
112
-
113
- The Squib DSL is based on a collection of methods provided to the `Squib::Deck` class. The general philosophy of Squib is to specify as little as possible with layers of defaults, highly flexible input, and good ol' Ruby duck-typing. Ruby does a lot to make Squib useful.
114
-
115
- Squib essentially has two main classes: `Deck` and `Card`. `Deck` is the front-end, and `Card` is the back-end. The contract of `Deck` is to do the various manipulations of options and then delegate the operation to `Card` to do the low-level graphical operations.
116
-
117
- For most users, I recommending solely using `Deck` methods. If you want to roll up your sleeves and get your hands messy, you can access the Cairo or Pango contexts the directly via the `Card` class. The API documentation doesn't really cover these, however, so you're on your own there.
118
-
119
- ## Specifying Parameters
120
-
121
- Squib is all about sane defaults and shorthand specification. Arguments are almost always using hashes, which look a lot like [Ruby 2.0's named parameters](http://www.ruby-doc.org/core-2.0.0/doc/syntax/calling_methods_rdoc.html#label-Keyword+Arguments). This means you can specify your parameters in any order you please. All parameters are optional. For example `x` and `y` default to 0 (i.e. the upper-left corner of the card). Any parameter that is specified in the command overrides any Squib defaults, `config.yml` settings, or layout rules.
122
-
123
- Note: you MUST use named parameters rather than positional parameters. For example: `save :png` will lead to an error like this:
124
-
125
- C:/Ruby200/lib/ruby/gems/2.0.0/gems/squib-0.0.3/lib/squib/api/save.rb:12:in `save': wrong number of arguments (2 for 0..1) (ArgumentError)
126
- from deck.rb:22:in `block in <main>'
127
- from C:/Ruby200/lib/ruby/gems/2.0.0/gems/squib-0.0.3/lib/squib/deck.rb:60:in `instance_eval'
128
- from C:/Ruby200/lib/ruby/gems/2.0.0/gems/squib-0.0.3/lib/squib/deck.rb:60:in `initialize'
129
- from deck.rb:18:in `new'
130
- from deck.rb:18:in `<main>'
131
-
132
- Instead, you must name the parameters: `save format: :png`
133
-
134
- ## Arrays and Singleton Expansion
135
-
136
- Many inputs to Squib can accept `Arrays`, which correspond to the entire deck. In fact, under the hood, if Squib is _not_ given an array, it expands it out to an array before rendering. This allows for different styles to apply to different cards. This example comes from the [ranges.rb example](https://github.com/andymeneely/squib/tree/master/samples/ranges.rb)
137
-
138
- ```ruby
139
- # This renders three cards, with three strings that had three different colors at three different locations.
140
- text str: %w(red green blue),
141
- color: [:red, :green, :blue],
142
- x: [40, 80, 120],
143
- y: [700, 750, 800]
144
- ```
145
-
146
- Under the hood, Squib actually views every argument as applied each card individually. If a single argument is given to the command, it's considered a singleton that gets expanded into a deck-sized array. Supplying the array bypasses that expansion - which means that any array you supply instead of a singleton ought to be the same size as the deck and align the same way the indexes in the supplied `range` are. If you don't, Ruby will fill that up with nils and not apply the rule across those cards.
147
-
148
- ## Specifying Ranges
149
-
150
- Most public `Deck` methods allow a `range` to be specified as a first parameter. This parameter is used to access an internal `Array` of `Squib::Cards`. This can be an actual Ruby range, or anything that implements `#each` (thus can be an `Enumerable`). Integers are also supported for changing one card only. Negatives work from the back of the deck. Here are some examples from `samples/ranges.rb` found [here](https://github.com/andymeneely/squib/tree/master/samples/ranges.rb)
151
-
152
- {include:file:samples/ranges.rb}
153
-
154
- ## Units
155
-
156
- By default, Squib thinks in pixels. This decision was made so that we can have pixel-perfect layouts without automatically scaling everything, even though working in units is sometimes easier. We provide some conversion methods, including looking for strings that end in "in" and "cm" and computing based on the current DPI. The dpi is set on `Squib::Deck.new` (not `config.yml`). Example is in `samples/units.rb` found [here](https://github.com/andymeneely/squib/tree/master/samples/units.rb)
157
-
158
- {include:file:samples/units.rb}
159
-
160
- ## Specifying Colors & Gradients
161
-
162
- Colors can be specified in a wide variety of ways, mostly in a hex-string. Take a look at the examples from `samples/colors.rb`, found [here](https://github.com/andymeneely/squib/tree/master/samples/colors.rb)
163
-
164
- {include:file:samples/colors.rb}
165
-
166
- Under the hood, Squib uses the `rcairo` [color parser](https://github.com/rcairo/rcairo/blob/master/lib/cairo/color.rb) to accept a variety of color specifications, along with over [300 pre-defined constants](https://github.com/rcairo/rcairo/blob/master/lib/cairo/colors.rb). The above sample will generate a table of such constants.
167
-
168
- Additionally, in most places where colors are allowed, you may also supply a string that defines a gradient. Squib supports two flavors of gradients: linear and radial. Gradients are specified by supplying some xy coordinates, which are relative to the card (not the command). Each stop must be between 0.0 and 1.0, and you can supply as many as you like. Colors can be specified as above (in any of the hex notations or built-in constant). If you add two (or more) colors at the same stop, then the gradient keeps the colors in the in order specified and treats it like sharp transition.
169
-
170
- The format for gradient strings look like this:
171
-
172
- Linear:
173
- ```
174
- (x1,y1)(x2,y2) color1@stop1 color2@stop2
175
- ```
176
- The xy coordinates define the angle of the gradient.
177
-
178
- Radial:
179
- ```
180
- (x1,y1,radius1)(x2,y2,radius2) color1@stop1 color2@stop2
181
- ```
182
- The coordinates specify an inner circle first, then an outer circle.
183
-
184
- Check out the following sample from `samples/gradients.rb`, found [here](https://github.com/andymeneely/squib/tree/master/samples/colors.rb)
185
-
186
- {include:file:samples/gradients.rb}
187
-
188
- ## Specifying Files
189
-
190
- All files opened for reading or writing (e.g. for `png` and `xlsx`) are opened relative to the current directory. Files opened for writing (e.g. for `save_png`) will be overwritten without warning.
191
-
192
- If you find that you `cd` a lot while working on the command line, your `_output` folder might get generated in multiple places. An easy way to fix this is to use a `Rakefile`, [see below](#Rakefile)
193
-
194
- ## Working with Text
195
- The `text` method is a particularly powerful method with a ton of options. Be sure to check the [API docs](/squib/doc/Squib/Deck#text-instance_method) on an option-by-option discussion, but here are the highlights.
196
-
197
- ###Fonts.
198
-
199
- To set the font, your `text` method call will look something like this:
200
-
201
- ```ruby
202
- text str: "Hello", font: 'MyFont Bold 32'
203
- ```
204
-
205
- The `'MyFont Bold 32'` is specified as a "Pango font string", which can involve [a lot of options](http://ruby-gnome2.osdn.jp/hiki.cgi?Pango%3A%3AFontDescription#Pango%3A%3AFontDescription.new) including backup font families, size, all-caps, stretch, oblique, italic, and degree of boldness. (These options are only available if the underlying font supports them, however.) Here's are some `text` calls with different Pango font strings:
206
-
207
- ```
208
- text str: "Hello", font: 'Sans 18'
209
- text str: "Hello", font: 'Arial,Verdana weight=900 style=oblique 36'
210
- text str: "Hello", font: 'Times New Roman,Sans 25'
211
- ```
212
-
213
- Note: When the font has a space in the name (e.g. Times New Roman), you'll need to put a backup to get Pango's parsing to work.
214
-
215
- It's also important to note that most of the font rendering is done by a combination of your installed fonts, your OS, and your graphics card. Thus, different systems will render text slightly differently.
216
-
217
- Fonts can also be set globally using the `set` method. For example:
218
-
219
- ```
220
- set font: 'Arial 26'
221
- text str: 'blah' # in Arial 26
222
- ```
223
-
224
- Furthermore, Squib's `text` method has options such as `font_size` that allow you to override the font string. This means that you can set a blanket font for the whole deck, then adjust sizes from there. This is useful with layouts and `extends` too.
225
-
226
- ### Width and Height
227
-
228
- By default, Pango text boxes will scale the text box to whatever you need, hence the `:native` default. However, for most of the other customizations to work (e.g. center-aligned) you'll need to specify the width. If both the width and the height are specified and the text overflows, then the `ellipsize` option is consulted to figure out what to do with the overflow. Also, the `valign` will only work if `height` is also set to something other than `:native`.
229
-
230
- ###Hints
231
-
232
- Laying out text by typing in numbers can be confusing. What Squib calls "hints" is merely a rectangle around the text box. Hints can be turned on globally in the config file, using the `set` method, or in an individual text method. These are there merely for prototyping and are not intended for production. Additionally, these are not to be conflated with "rendering hints" that Pango and Cairo mention in their documentation.
233
-
234
- ###Extents
235
-
236
- Sometimes you want size things based on the size of your rendered text. For example, drawing a rectangle around card's title such that the rectangle perfectly fits. Squib returns the final rendered size of the text so you can work with it afterward. It's an array of hashes that correspond to each card. The output looks like this:
237
-
238
- ```ruby
239
- Squib::Deck.new(cards: 2) do
240
- extents = text(str: ['Hello', 'World!'])
241
- p extents
242
- end
243
- ```
244
- Will output:
245
- ```
246
- [{:width=>109, :height=>55}, {:width=>142, :height=>55}] # Hello was 109 pixels wide, World 142 pixels
247
- ```
248
-
249
- ###Embedding Images
250
-
251
- Squib can embed icons into the flow of text. To do this, you need to define text keys for Squib to look for, and then the corresponding files. The object given to the block is a [TextEmbed](docs/Squib/TextEmbed), which supports PNG and SVG. Here's a minimal example:
252
-
253
- ```ruby
254
- text(str: 'Gain 1 :health:') do |embed|
255
- embed.svg key: ':health:', file: 'heart.svg'
256
- end
257
- ```
258
-
259
- ###Markup
260
-
261
- If you want to do specialized formatting within a given string, Squib has lots of options. By setting `markup: true`, you enable tons of text processing. This includes:
262
-
263
- * Pango Markup. This is an HTML-like formatting language that specifies formatting inside your string. Pango Markup essentially supports any formatting option, but on a letter-by-letter basis. Such as: font options, letter spacing, gravity, color, etc. See the [Pango docs](https://developer.gnome.org/pango/stable/PangoMarkupFormat.html) for details.
264
- * Quotes are converted to their curly counterparts where appropriate (i.e. &ldquo;smart quotes&rdquo; instead of "straight quotes").
265
- * Apostraphes are converted to curly as well.
266
- * LaTeX-style quotes are explicitly converted (<tt>``like this''</tt>)
267
- * Em-dash and en-dash are converted with triple and double-dashes respectively (<tt>--</tt> is an en-dash, and <tt>---</tt> becomes an em-dash.)
268
- * Ellipses can be specified with <tt>...</tt>. Note that this is entirely different from the `ellipsize` option (which determines what to do with overflowing text).
269
-
270
- A few notes:
271
- * Smart quoting assumes the UTF-8 character set.
272
- * Pango markup uses an XML/HTML-ish processor. Some characters require HTML-entity escaping (e.g. `&amp;` for `&')
273
-
274
- ### Text Sample
275
- ```yaml
276
- lsquote: "\u2018" #note that Yaml wants double quotes here to use escape chars
277
- rsquote: "\u2019"
278
- ldquote: "\u201C"
279
- rdquote: "\u201D"
280
- em_dash: "\u2014"
281
- en_dash: "\u2013"
282
- ellipsis: "\u2026"
283
- ```
284
-
285
- You can also disable the auto-quoting mechanism by setting `smart_quotes: false` in your config. Explicit replacements will still be performed.
286
-
287
- ### Text Samples
288
-
289
- Examples of all of the above are crammed into the `text_options.rb` sample [found here](https://github.com/andymeneely/squib/tree/master/samples/text_options.rb).
290
-
291
- {include:file:samples/text_options.rb}
292
-
293
- The `embed_text.rb` sample has more examples of embedding text, which can be [found here](https://github.com/andymeneely/squib/tree/master/samples/embed_text.rb).
294
-
295
- {include:file:samples/embed_text.rb}
296
-
297
- The `config_text_markup.rb` sample demonstrates how quoting can be configured, [found here](https://github.com/andymeneely/squib/tree/master/samples/config_text_markup.rb)
298
-
299
- {include:file:samples/config_text_markup.rb}
300
-
301
-
302
- ## Custom Layouts
303
-
304
- Working with x-y coordinates all the time can be tiresome, and ideally everything in a game prototype should be data-driven and easily changed. For this, many Squib methods allow for a `layout` to be set. In essence, layouts are a way of setting default values for any argument given to the command.
305
-
306
- To use a layout, set the `layout:` option on a `Deck.new` command to point to a YAML file. Any command that allows a `layout` option can be set with a Ruby symbol or String, and the command will then load the specified `x`, `y`, `width`, and `height`. The individual command can also override these options.
307
-
308
- Instead of this:
309
- ```ruby
310
- # deck.rb
311
- Squib::Deck.new(layout: 'custom-layout.yml') do
312
- rect x: 75, y: 75, width: 675, height: 975
313
- end
314
- ```
315
-
316
- You can put your logic in the layout file and reference them:
317
- ```yaml
318
- # custom-layout.yml
319
- frame:
320
- x: 75
321
- y: 75
322
- width: 975
323
- height: 675
324
- ```
325
- Then your script looks like this:
326
- ```ruby
327
- # deck.rb
328
- Squib::Deck.new(layout: 'custom-layout.yml') do
329
- rect layout: 'frame'
330
- end
331
- ```
332
- The goal is to make your Ruby code more separate data from logic, which in turn makes your code more readable and maintainable. With `extends` (see below), layouts become even more powerful in keeping you from repeating yourself.
333
-
334
- Note: YAML is very finnicky about not allowing tab characters. Use two spaces for indentation instead. If you get a `Psych` syntax error, this is likely the culprit. Indendation is also strongly enforced in Yaml too. See the [Yaml docs](http://www.yaml.org/YAML_for_ruby.html).
335
-
336
- ### Order of Precedence
337
-
338
- Layouts will override Squib's system defaults, but are overriden by anything specified in the command itself. Thus, the order of precedence looks like this:
339
-
340
- * Use what the command specified
341
- * If anything was not yet specified, use what was given in a layout (if a layout was specified in the command and the file was given to the Deck)
342
- * If still anything was not yet specified, use what was given in Squib's defaults.
343
-
344
- ### Special key: `extends`
345
-
346
- Squib provides a way of reusing layouts with the special `extends` key. When defining an `extends` key, we can merge in another key and modify data coming in if we want to. This allows us to do things like place text next to an icon and be able to move them with each other. Like this:
347
-
348
- ```yaml
349
- # If we change the xy of attack, we move defend too!
350
- attack:
351
- x: 100
352
- y: 100
353
- radius: 100
354
- defend:
355
- extends: attack
356
- x: += 50
357
- #defend now is {:x => 150, :y => 100}
358
- ```
359
-
360
- If you want to extend multiple parents, it looks like this:
361
-
362
- ```yaml
363
- socrates:
364
- x: 100
365
- plato:
366
- y: 200
367
- aristotle:
368
- extends:
369
- - socrates
370
- - plato
371
- x: += 50
372
- ```
373
- If multiple keys override the same keys in a parent, the later ("younger") child takes precedent.
374
-
375
- Note that extends keys are similar to Yaml's ["merge keys"](http://www.yaml.org/YAML_for_ruby.html#merge_key). With merge keys, you can define base styles in one entry, then include those keys elsewhere. For example:
376
-
377
- ```yaml
378
- icon: &icon
379
- width: 50
380
- height: 50
381
- icon_left
382
- <<: *icon
383
- x: 100
384
- # The layout for icon_left will have the width/height from icon!
385
- ```
386
-
387
- If you use both `extends` and Yaml merge keys, the Yaml merge keys are processed first, then extends. For clarity, however, you're probably just better off using `extends` exclusively.
388
-
389
- ### Multiple layout files
390
-
391
- Squib also supports the combination of multiple layout files. If you provide an `Array` of files then Squib will merge them sequentially. Colliding keys will be completely re-defined by the later file. Extends is processed after _each file_. Here's a complex example:
392
-
393
- ```yaml
394
- # load order: a.yml, b.yml
395
-
396
- ##############
397
- # file a.yml #
398
- ##############
399
- grandparent:
400
- x: 100
401
- parent_a:
402
- extends: grandparent
403
- x: += 10 # evaluates to 110
404
- parent_b:
405
- extends: grandparent
406
- x: += 20 # evaluates to 120
407
-
408
- ##############
409
- # file b.yml #
410
- ##############
411
- child_a:
412
- extends: parent_a # i.e. extends a layout in a separate file
413
- x: += 3 # evaluates to 113 (i.e 110 + 3)
414
- parent_b: # redefined
415
- extends: grandparent
416
- x: += 30 # evaluates to 130 (i.e. 100 + 30)
417
- child_b:
418
- extends: parent_b
419
- x: += 3 # evaluates to 133 (i.e. 130 + 3)
420
- ```
421
-
422
- This can be helpful for:
423
- * Creating a base layout for structure, and one for color (for easier color/black-and-white switching)
424
- * Sharing base layouts with other designers
425
-
426
- YAML merge keys are NOT supported across multiple files - use `extends` instead.
427
-
428
- ### Built-in Layout Files
429
-
430
- Why mess with x-y coordinates when you're first prototyping your game?!?!? Just use a built-in layout to get your game to the table as quickly as possible.
431
-
432
- If your layout file is not found in the current directory, Squib will search for its own set of layout files. The latest the development version of these can be found [on GitHub](https://github.com/andymeneely/squib/tree/master/lib/squib/layouts). The `layouts_builtin.rb` sample (found [here](https://github.com/andymeneely/squib/tree/master/samples/)) demonstrate built-in layouts based on popular games (e.g. `fantasy.yml` and `economy.yml`)
433
-
434
- Contributions in this area are particularly welcome!
435
-
436
- ### Layout Sample
437
- This sample demonstrates many different ways of using and combining layouts. This is the `layouts.rb` sample found [here](https://github.com/andymeneely/squib/tree/master/samples/)
438
-
439
- {include:file:samples/layouts.rb}
440
-
441
- ## Backends: Raster vs. Vector
442
- Under the hood, Cairo has the ability to support a variety of surfaces to draw on, including both raster images stored in memory and vectors stored in SVG files. Thus, Squib supports the ability to handle both. They are options in the configuration file `backend: memory` or `backend: svg`.
443
-
444
- If you save to a PDF then the backend will determine how your cards are saved too. For `memory`, the PDF will be filled with compressed raster images and be a larger file (yet it will still print at high quality... see discussion below). For SVG backends, PDFs will be smaller. If you have your deck backed by SVG, then the cards are auto-saved, so there is no `save_svg` in Squib. (Technically, the operations are stored and then flushed to the SVG file at the very end.)
445
-
446
- There are trade-offs that one should consider here.
447
-
448
- * _Print quality is **higher** for raster images_. This seems counterintuitive at first, but consider where Squib sits in your workflow. It's the final assembly line for your cards before they get printed. Cairo puts _a ton_ of work into rendering each pixel perfectly when it works with raster images. Printers, on the other hand, don't think in vectors and will render your paths in their own memory with their own embedded libraries without putting a lot of work into antialiasing and various other graphical esoterica. You may notice that print-on-demand companies such as The Game Crafter [only accept raster file types](https://www.thegamecrafter.com/help/supported-file-types), because they don't want their customers complaining about printers not rendering vectors with enough care.
449
- * _PDFs are **smaller** for SVG back ends_. If file size is a limitation for you, and it can be for some printers or internet forums, then an SVG back end for vectorized PDFs is the way to go.
450
- * _Squib is **greedy** with memory_. While I've tested Squib with big decks on older computers, the `memory` backend is quite greedy with RAM. If memory is at a premium for you, switching to SVG might help.
451
-
452
- Note: you can still load PNGs into an SVG-backed deck and load SVGs into a memory-backed deck. To me, the sweet spot is to keep all of my icons, text, and other stuff in vector form for infinite scaling and then render them all to pixels with Squib.
453
-
454
- Fortunately, switching backends in Squib should be as trivial as changing the setting in the config file. So go ahead and experiment with both and see what works for you. See below for how the configuration options work.
455
-
456
- ## Configuration File
457
-
458
- Squib supports various configuration properties that can be specified in an external file. The `config:` option in `Deck.new` can specify an optional configuration file in YML format. The properties there are intended to be immutable for the life of the Deck. The options include:
459
-
460
- * `progress_bars` (Boolean, default: false). When set to `true`, long-running operations will show a progress bar on the command line.
461
- * `hint` (ColorString, default: off). Text hints are used to show the boundaries of text boxes. Can be enabled/disabled for individual commands, or set globally with the `set` command. This setting is overriden by `set` and individual commands.
462
- * `custom_colors` (Hash of Colors, default: {}). Defines globally-available colors available to the deck that can be specified in commands.
463
- * `antialias` (`fast, good, best, none, gray, subpixel`, default: best). Set the algorithm that Cairo will use for antialiasing. Using our benchmarks on large decks, `best` is only ~10% slower anyway. For more info see the [Cairo docs](http://www.cairographics.org/manual/cairo-cairo-t.html#cairo-antialias-t).
464
- * `backend` (`svg` or `memory`, default: `memory`). Defines how Cairo will store the operations. Memory is recommended for higher quality rendering.
465
- * `prefix` (default: `card_`). When using an SVG backend, cards are auto-saved with this prefix and `"%02d"` numbering format.
466
-
467
- For debugging/sanity purposes, if you want to make sure your configuration options are parsed correclty, the above options are also available as methods within Squib::Deck, for example:
468
-
469
- ```ruby
470
- Squib::Deck.new do
471
- puts backend # prints 'memory' by default
472
- end
473
- ```
474
-
475
- The following sample demonstrates the config file, found [here](https://github.com/andymeneely/squib/tree/master/samples/)
476
-
477
- {include:file:samples/custom_config.rb}
478
-
479
- ## Importing from Excel and CSV
480
-
481
- Squib supports importing data from `xlsx` files and `csv` files. These methods are column-based, which means that they assume you have a header row in your table, and that header row will define the column. Squib will return a `Hash` of `Arrays` correspoding to each row. Warnings are thrown on things like duplicate columns. See the `excel.rb` and the `csv_import.rb` sample found [here](https://github.com/andymeneely/squib/tree/master/samples/).
482
-
483
- {include:file:samples/excel.rb}
484
-
485
- Of course, you can always import your game data other ways using just Ruby. There's nothing special about Squib's methods other than their convenience.
486
-
487
- ###Quantity Explosion
488
-
489
- If you want more than one copy of a card, then have a column called `Qty` and fill it with counts. Squib's `xlsx` and `csv` methods will automatically expand those rows according to those counts. You can also customize that "Qty" to anything you like by setting the `explode` option (e.g. `explode: 'Quantity'`). See the `excel.rb` and the `csv_import.rb` samples found [here](https://github.com/andymeneely/squib/tree/master/samples/) for an example.
490
-
491
- ## Making Squib Verbose
492
-
493
- By default, Squib's logger is set to WARN, but more fine-grained logging is embedded in the code. To set the logger, just put this at the top of your script:
494
-
495
- ```ruby
496
- Squib::logger.level = Logger::INFO
497
- ```
498
-
499
- If you REALLY want to see tons of output, you can also set DEBUG, but that's not intended for general consumption.
500
-
501
- # "Best" Practices
502
-
503
- Here's a collection of workflow tips and code snippets that will hopefully improve your Squibbing. Contributions are welcome!
504
-
505
- ## Staying DRY
506
-
507
- Squib tries to keep you DRY (Don't Repeat Yourself) with the following features:
508
-
509
- * Custom layouts allow you to specify various arguments in a separate file. This is great for x-y coordinates and alignment properties that would otherwise clutter up perfectly readable code. Squib goes even further and has a special "extends" that works especially well for grouped-together styles.
510
- * Flexible ranges and array handling: the `range` parameter in Squib is very flexible, meaning that one `text` command can specify different text in different fonts, styles, colors, etc. for each card. If you find yourself doing multiple `text` command for the same field across different ranges of cards, there's probably a better way to condense.
511
- * Custom colors keep you from hardcoding magic color strings everywhere. Custom colors go into `config.yml` file.
512
- * Plus, you know, Ruby.
513
-
514
- ## Get to know Ruby's Array and Enumerable
515
-
516
- Don't know Ruby? Welcome! We are so happy that Squib is your excuse to learn Ruby.
517
-
518
- Ruby has a *very* rich library for all of its built-in data types, especially [Array](http://ruby-doc.org/core-2.2.0/Array.html), and it's broader module [Enumerable](http://ruby-doc.org/core-2.2.0/Enumerable.html). Since Squib primarily takes in arrays into most of its fields, getting to know these methods will help you out enormously:
519
-
520
- * [Array#each](http://ruby-doc.org/core-2.2.0/Array.html#method-i-each) - do something on each element of the array (Ruby folks seldom use for-loops)
521
- * [Array#map](http://ruby-doc.org/core-2.2.0/Array.html#method-i-map) - do something on each element of an array and put it into a new array
522
- * [Array#select](http://ruby-doc.org/core-2.2.0/Array.html#method-i-select) - select a subset of an array
523
- * [Enumerable#each_with_index](http://ruby-doc.org/core-2.2.0/Enumerable.html#method-i-each_with_index) - do something to each element, also being aware of the index
524
- * [Array#zip](http://ruby-doc.org/core-2.2.0/Enumerable.html#method-i-zip) - combine two arrays, element by element
525
-
526
- ## Source control
527
-
528
- You are using source control, right??
529
-
530
- By default, Squib assumes Git. But it's not dogmatic about it. Tracking your progress, backing up, sharing data, topic branches, release management, and reverting into history are just some of the many, many useful things you can do with source control. For me, I tend to ignore any auto-generated files in my output folder, but version control everything else. I also try to keep my graphics vector files, so the files stay small. Version control is intended for source code, so large binary files that change often probably should not get checked in unless absolutely necessary. I tend to keep big raster graphics files (e.g. from Gimp) in cloud storage or elsewhere.
531
-
532
- ## SublimeText
533
-
534
- Using SublimeText? I like you already. I've written up some Squib snippets to ease remembering Squib commands. It's called `Squib Snippets` on Package Control. Compatible with SublimeText 3. Source code is also [on Github](https://github.com/andymeneely/sublime-squib) (contributions welcome!). Check it out:
535
-
536
- ![Sublime Squib Snippets](https://raw.githubusercontent.com/andymeneely/squib/screencasts/sublime-squib-snippets.gif)
537
-
538
- ## Decks with multiple orientations or sizes
539
-
540
- If you want to make a deck that has some portrait and some landscape cards, I recommend you use multiple `Squib::Deck`s. The pixel size of a given card is designed to not change thorughout the life of a `Squib::Deck`. To work with landscape cards, there is a `rotate` option on `save_png` so you can render your print-on-demand PNGs in portrait but keep everything else oriented toward landscape. The following example demonstrates how to do this, found [here](https://github.com/andymeneely/squib/tree/master/samples/portrait-landscape.rb).
541
-
542
- {include:file:samples/portrait-landscape.rb}
543
-
544
- ## Rakefile
545
-
546
- When you run `squib new`, you are given a basic Rakefile. At this stage of Squib, it's basically just a shortcut for `ruby deck.rb`. But, even in this simple form this Rakefile has some advantages:
547
-
548
- * If you're in a subdirectory at the time, `rake` will simply traverse up and `cd` to the proper directory so you don't get rogue `_output` directories
549
- * If you find yourself building multiple decks, you can make your own tasks for each one individually, or all (e.g. `rake marketing`)
550
- * Don't need the `require squib` at the top of your code (although that breaks `ruby deck.rb`, so that's probably a bad idea)
551
-
552
- ## Using Google Sheets
553
-
554
- We don't officially support Google Sheets ([yet](https://github.com/andymeneely/squib/issues/49)), but [this Gist](https://gist.github.com/pickfifteen/aeee73ec2ce162b0aee8) might be helpful in automatically exporting the CSV.
555
-
556
- ## Combining Multiple Columns
557
-
558
- Say you have multiple columns in your Excel sheet that need to be combined into one text field on your card. Consider using `zip` in conjunction with `map`.
559
-
560
- ```ruby
561
- data['BuyText'] = data['BuyAmount'].zip(data['BuyType']).map do |amt, type|
562
- "You may purchase #{amt} #{type}" #e.g. You may purchase 1 Wood.
563
- end
564
-
565
- data['Cost'] = data['Action Cost'].zip(data['Card Cost']).map do |ac, cc|
566
- ':action:' * ac.to_i + ":card#{cc}:"
567
- end
568
- ```
569
-
570
- Second example adapted from [this conversation](https://github.com/andymeneely/squib/issues/90)
571
-
572
- # Get Involved
573
-
574
- Squib is an open source tool, so I welcome participation. Squib is currently in pre-release alpha, so the API is still maturing. I do change my mind about the names and meaning of things at this stage. I will document these changes as best as I can.
575
-
576
- I also highly recommend upgrading to new versions of Squib every chance you get (using Bundler). You can watch for new upgrades by following the RubyGems [RSS](https://rubygems.org/gems/squib/versions.atom), or by watching the project on GitHub.
577
-
578
- For bugs and feature requests, feel free to [file a bug or feature request](https://github.com/andymeneely/squib/issues). A minimal code example along with your OS and Ruby details would be ideal.
579
-
580
- ## New to Programming?
581
-
582
- I often hear statements like "I'm not a programmer, but I want to use Squib." If you want to use Squib, then maybe you really were a programmer all along :)
583
-
584
- Squib is a Ruby library. To learn Squib, you will need to learn Ruby. There is no getting around that fact. Don't fight it, embrace it.
585
-
586
- Fortunately, Ruby is wonderfully rich in features and very expressive in its syntax. Ruby has a vibrant, friendly community (much like tabletop game designers!). Ruby is the language of choice for many new programmers, including many universities. Plus, learning how to code is ubiquitous on the Internet.
587
-
588
- Doubly fortunately, Squib doesn't require tons of Ruby-fu to get going either. The main things you'll need to know are:
589
- * Working on the command line
590
- * Ruby Arrays, so that the `range` parameter makes more sense
591
- * Strings, variables, and symbols
592
- * If you are using Excel or CSV, then Ruby hashes are worth a glance.
593
- * Working iteratively: making small edits and run your code frequently (every few minutes)
594
-
595
- Anything related to Ruby on Rails is not necessary to learn for Squib. Rails is a heavyweight framework for web development (awesome in its own way, but not relevant to learning Ruby). Squib is about scripting.
596
-
597
- ## Get Help
598
-
599
- There are lots of people using Squib already. If you've gone through the [samples](https://github.com/andymeneely/squib/tree/master/samples) and still have questions, here are some other places to get help.
600
-
601
- * Our [thread on BoardGameGeek](http://boardgamegeek.com/thread/1293453) is quite active and informal (if a bit unstructured).
602
- * [StackOverflow](http://stackoverflow.com/questions/ask?tags=ruby squib) with the tag "ruby" and "squib" will get you answers quickly and a great way to document questions for future Squibbers.
603
-
604
- If you email me directly I'll probably ask you to post your question publicly so we can document answers for future Googling Squibbers.
605
-
606
- Please use GitHub issues for bugs and feature requests.
607
-
608
- ## Give Help
609
-
610
- Let's help each other out! Even if you're relatively new, there's probably some question out there that you can help answer. Here's how to help:
611
-
612
- * Subscribe to our thread on BoardGameGeek (see above for link)
613
- * Subscribe to alerts from Stackoverflow for the tags "squib" and "ruby"
614
- * Post snippets of your code using GitHub gists
615
- * Write a how-to tutorial and post it on [our wiki](https://github.com/andymeneely/squib/wiki)
616
-
617
- ## Testing Pre-Builds
618
-
619
- Testers needed!! If you want to test new features as I develop them, or make sure I didn't break your code, you can always point your Gemfile to the repository and follow what I'm doing there. Your Gemfile specification looks like this:
620
-
621
- ```ruby
622
- gem 'squib', git: 'git://github.com/andymeneely/squib', branch: 'dev'
623
- ```
624
- * The `dev` branch is where I am working on features in-process. I have not done much regression testing at this point, but would love testing feedback nonetheless.
625
- * The `master` branch is where I consider features and bug that are done and tested, but not released yet.
626
-
627
- ## Contributing
628
-
629
- If you want your code integrated:
630
-
631
- 1. Fork the git repository ( https://github.com/[my-github-username]/squib/fork )
632
- 2. Create your feature branch (`git checkout -b my-new-feature`)
633
- 3. Commit your changes (`git commit -am 'Add some feature'`)
634
- 4. Push to the branch (`git push origin my-new-feature`)
635
- 5. Create a new Pull Request
636
-
637
- Be sure to run the unit tests and packaging with just `rake`. Also, you can check that the samples render properly with `rake sanity`.
638
-
639
- # What's up the with the name?
640
-
641
- Truthfully, I just thought it was a cool, simple word that was not used much in the Ruby community nor the board game community. But, now that I've committed to the name, I've realized that:
642
-
643
- * Squibs are small explosive devices, much like Squib "explodes" your rules into a playable game
644
- * Squibs are often used in heist movies, leading to a sudden plot twist that often resembles the twists of good tabletop game
645
- * Squibs are also part of the Harry Potter world - they are people who are non-magical but wizard-born. Squib is aware of wizarding magic and comes from that heritage, but it's not magical itself.
1
+ # Squib [![Gem Version](https://badge.fury.io/rb/squib.svg)](https://rubygems.org/gems/squib) [![Build Status](https://secure.travis-ci.org/andymeneely/squib.svg?branch=master)](https://travis-ci.org/andymeneely/squib) [![Vey][vey]][vey_url] [![Dependency Status](https://gemnasium.com/andymeneely/squib.svg)](https://gemnasium.com/andymeneely/squib) [![Coverage Status](https://img.shields.io/coveralls/andymeneely/squib.svg)](https://coveralls.io/r/andymeneely/squib) [![Inline docs](http://inch-ci.org/github/andymeneely/squib.png?branch=master)](http://inch-ci.org/github/andymeneely/squib)
2
+ Squib is a Ruby [DSL](http://en.wikipedia.org/wiki/Domain-specific_language) for prototyping card and board games. Write a little bit of Ruby, define your deck's stats, then compile your game into a series of images ready for print-and-play or even print-on-demand. Squib is very data-driven and built on the principle of Don't Repeat Yourself. Think of it like [nanDeck](http://www.nand.it/nandeck/) done "the Ruby way". Squib supports:
3
+
4
+ [vey]: https://ci.appveyor.com/api/projects/status/github/andymeneely/squib?svg=true
5
+ [vey_url]: https://ci.appveyor.com/project/andymeneely/squib
6
+
7
+ * A concise set of rules for laying out your cards
8
+ * Loading PNGs and SVGs
9
+ * Complex text rendering using [Pango](http://www.pango.org/)
10
+ * Reading `xlsx` and `csv` files
11
+ * Rendering to PNGs, PDFs, and SVGs (sheets or individual files)
12
+ * Flexible, data-driven layouts in Yaml
13
+ * Basic shape drawing, blending operators, gradients, etc.
14
+ * Unit conversion
15
+ * The full power of Ruby!
16
+
17
+ Squib is based on the [Cairo](http://cairographics.org/) graphics rendering engine, the library of choice for WebKit, Gecko, Inkscape and many, many others.
18
+
19
+ Check this out.
20
+
21
+ ```ruby
22
+ require 'squib'
23
+
24
+ Squib::Deck.new(cards: 2) do
25
+ text str: %w(Hello World!)
26
+ save_png
27
+ end
28
+ ```
29
+
30
+ We just created a 2-card deck with "Hello" on the first card, and "World" on the second, and saved them out to PNGs.
31
+
32
+ ## Installation
33
+
34
+ Squib requires Ruby 2.0 or later.
35
+
36
+ Install it yourself with:
37
+
38
+ $ gem install squib
39
+
40
+ If you're using Bundler, add this line to your application's Gemfile:
41
+
42
+ gem 'squib'
43
+
44
+ And then execute:
45
+
46
+ $ bundle
47
+
48
+ Note: Squib has some native dependencies, such as [Cairo](https://github.com/rcairo/rcairo), [Pango](http://ruby-gnome2.sourceforge.jp/hiki.cgi?Pango%3A%3ALayout), and [Nokogiri](http://nokogiri.org/), which may require compiling C code to install. This is usually not painful at all, and is automated through Bundler/RubyGems, but can cause headaches on some setups.
49
+ * Windows: I recommend using the *non-64 bit* RubyInstaller at http://rubyinstaller.org. Some installations will also need DevKit. Currently, Ruby 2.2 on Windows conflicts with one of Squib's dependencies called Nokogiri (read the WTF-y issue here: https://github.com/sparklemotion/nokogiri/issues/1256) UPDATE: their pre-releases have fixed this exact issue - just install nokogiri-1.6.7.rc3-x64-mingw32 (or higher). Or, as a last resort, use 2.1 or 2.0 for Windows users.
50
+ * Mac: I recommend using [rvm](https://rvm.io). Some users have reported that Ruby 2.1 will not work with Mac OSX 10.10.4 (#88) - Ruby 2.0 and 2.2 are confirmed to work however (this is an rcairo issue, not a Squib issue).
51
+ * Cywgin is not supported, but could theoretically work with extra installation steps. See [this thread](http://boardgamegeek.com/article/18508113#18508113). Contributions in this area are welcome.
52
+ * Linux. No known installation issues. Happy installing!
53
+
54
+ ## Getting Started
55
+
56
+ After installing Squib, you can create a project and run your first build like this:
57
+
58
+ ```sh
59
+ $ squib new my-cool-game
60
+ $ cd my-cool-game
61
+ $ ruby deck.rb
62
+ ```
63
+
64
+ The `squib new` command will generate files and folders like this:
65
+
66
+ ```
67
+ _output/gitkeep.txt
68
+ .gitignore
69
+ ABOUT.md
70
+ config.yml
71
+ deck.rb
72
+ Gemfile
73
+ layout.yml
74
+ PNP NOTES.md
75
+ ```
76
+
77
+ The central file here is `deck.rb`. Here's a [basic example](https://github.com/andymeneely/squib/tree/master/samples/basic.rb) of a deck to work from:
78
+
79
+ {include:file:samples/basic.rb basic.rb}
80
+
81
+ About the other files:
82
+ * `Gemfile` is for adding in other gems if you are using `bundler`
83
+ * `config.yml` is a skeleton config file with various options commented out. See {file:README.md#Configuration_File Configuration File}.
84
+ * `layout.yml` is a skeleton layout file if you want to use it. See {file:README.md#Custom_Layouts Custom Layouts}.
85
+ * `_output` is the directory where your built files will go. Can easily be changed, of course.
86
+ * `.gitignore` and `gitkeep.txt` are for if you are using Git. See {file:README.md#Source_control Source control}. (Feel free to remove these if you are not using Git.)
87
+ * `ABOUT.md` and `PHP NOTES.md` are Markdown files for posting. Not used by Squib, but there by convention.
88
+ * `Rakefile` is a basic build file. Not required but handy - see {file:README.md#Rakefile Rakefile}
89
+
90
+ # Learning Squib
91
+
92
+ In addition to this README, be sure to also check out the following resources for more details:
93
+
94
+ * The `samples` directory in the [source repository](https://github.com/andymeneely/squib) has lots of examples.
95
+ * [Iconoclast](https://github.com/andymeneely/iconoclast) is a basic set collection game I'm developing from scratch with Squib. Be sure to read the [commit history](https://github.com/andymeneely/iconoclast/commits/master) to see how the game has developed from scratch.
96
+ * [Junk Land](https://github.com/andymeneely/junk-land) is my own creation that's uses Squib for full-color rendering, and makes use of Ruby in a lot of interesting ways.
97
+
98
+ ## Viewing this README
99
+
100
+ The best place to read this documentation is on [our website](http://andymeneely.github.io/squib/doc). Be sure to check out the method-by-method documentation, particularly for the [Deck](Squib/Deck.html) class.
101
+
102
+ If you want to view it offline, you can do the following
103
+
104
+ ```sh
105
+ $ gem install yard
106
+ $ yard server --gems
107
+ ```
108
+ Then go to [http://localhost:8808/docs/squib/file/README.md](http://localhost:8808/docs/squib/file/README.md)
109
+
110
+ If you're viewing this on Github, you might see some confusing tags like `{include:file:...}` - these are directives for YARD to show the embedded examples. Github doesn't render those and you might find them helpful.
111
+
112
+ Also, RubyDoc.info linked from RubyGems appears to be perpetually broken and doesn't support `{include:file...}` directive properly, so the embedded samples will also not show up there, either.
113
+
114
+ ## Squib Decks and Cards
115
+
116
+ The Squib DSL is based on a collection of methods provided to the `Squib::Deck` class. The general philosophy of Squib is to specify as little as possible with layers of defaults, highly flexible input, and good ol' Ruby duck-typing. Ruby does a lot to make Squib useful.
117
+
118
+ Squib essentially has two main classes: `Deck` and `Card`. `Deck` is the front-end, and `Card` is the back-end. The contract of `Deck` is to do the various manipulations of options and then delegate the operation to `Card` to do the low-level graphical operations.
119
+
120
+ For most users, I recommending solely using `Deck` methods. If you want to roll up your sleeves and get your hands messy, you can access the Cairo or Pango contexts the directly via the `Card` class. The API documentation doesn't really cover these, however, so you're on your own there.
121
+
122
+ ## Specifying Parameters
123
+
124
+ Squib is all about sane defaults and shorthand specification. Arguments are almost always using hashes, which look a lot like [Ruby 2.0's named parameters](http://www.ruby-doc.org/core-2.0.0/doc/syntax/calling_methods_rdoc.html#label-Keyword+Arguments). This means you can specify your parameters in any order you please. All parameters are optional. For example `x` and `y` default to 0 (i.e. the upper-left corner of the card). Any parameter that is specified in the command overrides any Squib defaults, `config.yml` settings, or layout rules.
125
+
126
+ Note: you MUST use named parameters rather than positional parameters. For example: `save :png` will lead to an error like this:
127
+
128
+ C:/Ruby200/lib/ruby/gems/2.0.0/gems/squib-0.0.3/lib/squib/api/save.rb:12:in `save': wrong number of arguments (2 for 0..1) (ArgumentError)
129
+ from deck.rb:22:in `block in <main>'
130
+ from C:/Ruby200/lib/ruby/gems/2.0.0/gems/squib-0.0.3/lib/squib/deck.rb:60:in `instance_eval'
131
+ from C:/Ruby200/lib/ruby/gems/2.0.0/gems/squib-0.0.3/lib/squib/deck.rb:60:in `initialize'
132
+ from deck.rb:18:in `new'
133
+ from deck.rb:18:in `<main>'
134
+
135
+ Instead, you must name the parameters: `save format: :png`
136
+
137
+ ## Arrays and Singleton Expansion
138
+
139
+ Many inputs to Squib can accept `Arrays`, which correspond to the entire deck. In fact, under the hood, if Squib is _not_ given an array, it expands it out to an array before rendering. This allows for different styles to apply to different cards. This example comes from the [ranges.rb example](https://github.com/andymeneely/squib/tree/master/samples/ranges.rb)
140
+
141
+ ```ruby
142
+ # This renders three cards, with three strings that had three different colors at three different locations.
143
+ text str: %w(red green blue),
144
+ color: [:red, :green, :blue],
145
+ x: [40, 80, 120],
146
+ y: [700, 750, 800]
147
+ ```
148
+
149
+ Under the hood, Squib actually views every argument as applied each card individually. If a single argument is given to the command, it's considered a singleton that gets expanded into a deck-sized array. Supplying the array bypasses that expansion - which means that any array you supply instead of a singleton ought to be the same size as the deck and align the same way the indexes in the supplied `range` are. If you don't, Ruby will fill that up with nils and not apply the rule across those cards.
150
+
151
+ ## Specifying Ranges
152
+
153
+ Most public `Deck` methods allow a `range` to be specified as a first parameter. This parameter is used to access an internal `Array` of `Squib::Cards`. This can be an actual Ruby range, or anything that implements `#each` (thus can be an `Enumerable`). Integers are also supported for changing one card only. Negatives work from the back of the deck. Here are some examples from `samples/ranges.rb` found [here](https://github.com/andymeneely/squib/tree/master/samples/ranges.rb)
154
+
155
+ {include:file:samples/ranges.rb}
156
+
157
+ ## Units
158
+
159
+ By default, Squib thinks in pixels. This decision was made so that we can have pixel-perfect layouts without automatically scaling everything, even though working in units is sometimes easier. We provide some conversion methods, including looking for strings that end in "in" and "cm" and computing based on the current DPI. The dpi is set on `Squib::Deck.new` (not `config.yml`). Example is in `samples/units.rb` found [here](https://github.com/andymeneely/squib/tree/master/samples/units.rb)
160
+
161
+ {include:file:samples/units.rb}
162
+
163
+ ## Specifying Colors & Gradients
164
+
165
+ Colors can be specified in a wide variety of ways, mostly in a hex-string. Take a look at the examples from `samples/colors.rb`, found [here](https://github.com/andymeneely/squib/tree/master/samples/colors.rb)
166
+
167
+ {include:file:samples/colors.rb}
168
+
169
+ Under the hood, Squib uses the `rcairo` [color parser](https://github.com/rcairo/rcairo/blob/master/lib/cairo/color.rb) to accept a variety of color specifications, along with over [300 pre-defined constants](https://github.com/rcairo/rcairo/blob/master/lib/cairo/colors.rb). The above sample will generate a table of such constants.
170
+
171
+ Additionally, in most places where colors are allowed, you may also supply a string that defines a gradient. Squib supports two flavors of gradients: linear and radial. Gradients are specified by supplying some xy coordinates, which are relative to the card (not the command). Each stop must be between 0.0 and 1.0, and you can supply as many as you like. Colors can be specified as above (in any of the hex notations or built-in constant). If you add two (or more) colors at the same stop, then the gradient keeps the colors in the in order specified and treats it like sharp transition.
172
+
173
+ The format for gradient strings look like this:
174
+
175
+ Linear:
176
+ ```
177
+ (x1,y1)(x2,y2) color1@stop1 color2@stop2
178
+ ```
179
+ The xy coordinates define the angle of the gradient.
180
+
181
+ Radial:
182
+ ```
183
+ (x1,y1,radius1)(x2,y2,radius2) color1@stop1 color2@stop2
184
+ ```
185
+ The coordinates specify an inner circle first, then an outer circle.
186
+
187
+ Check out the following sample from `samples/gradients.rb`, found [here](https://github.com/andymeneely/squib/tree/master/samples/colors.rb)
188
+
189
+ {include:file:samples/gradients.rb}
190
+
191
+ ## Specifying Files
192
+
193
+ All files opened for reading or writing (e.g. for `png` and `xlsx`) are opened relative to the current directory. Files opened for writing (e.g. for `save_png`) will be overwritten without warning.
194
+
195
+ If you find that you `cd` a lot while working on the command line, your `_output` folder might get generated in multiple places. An easy way to fix this is to use a `Rakefile`, [see below](#Rakefile)
196
+
197
+ ## Working with Text
198
+ The `text` method is a particularly powerful method with a ton of options. Be sure to check the [API docs](/squib/doc/Squib/Deck#text-instance_method) on an option-by-option discussion, but here are the highlights.
199
+
200
+ ###Fonts.
201
+
202
+ To set the font, your `text` method call will look something like this:
203
+
204
+ ```ruby
205
+ text str: "Hello", font: 'MyFont Bold 32'
206
+ ```
207
+
208
+ The `'MyFont Bold 32'` is specified as a "Pango font string", which can involve [a lot of options](http://ruby-gnome2.osdn.jp/hiki.cgi?Pango%3A%3AFontDescription#Pango%3A%3AFontDescription.new) including backup font families, size, all-caps, stretch, oblique, italic, and degree of boldness. (These options are only available if the underlying font supports them, however.) Here's are some `text` calls with different Pango font strings:
209
+
210
+ ```
211
+ text str: "Hello", font: 'Sans 18'
212
+ text str: "Hello", font: 'Arial,Verdana weight=900 style=oblique 36'
213
+ text str: "Hello", font: 'Times New Roman,Sans 25'
214
+ ```
215
+
216
+ Note: When the font has a space in the name (e.g. Times New Roman), you'll need to put a backup to get Pango's parsing to work.
217
+
218
+ It's also important to note that most of the font rendering is done by a combination of your installed fonts, your OS, and your graphics card. Thus, different systems will render text slightly differently.
219
+
220
+ Fonts can also be set globally using the `set` method. For example:
221
+
222
+ ```
223
+ set font: 'Arial 26'
224
+ text str: 'blah' # in Arial 26
225
+ ```
226
+
227
+ Furthermore, Squib's `text` method has options such as `font_size` that allow you to override the font string. This means that you can set a blanket font for the whole deck, then adjust sizes from there. This is useful with layouts and `extends` too.
228
+
229
+ ### Width and Height
230
+
231
+ By default, Pango text boxes will scale the text box to whatever you need, hence the `:native` default. However, for most of the other customizations to work (e.g. center-aligned) you'll need to specify the width. If both the width and the height are specified and the text overflows, then the `ellipsize` option is consulted to figure out what to do with the overflow. Also, the `valign` will only work if `height` is also set to something other than `:native`.
232
+
233
+ ###Hints
234
+
235
+ Laying out text by typing in numbers can be confusing. What Squib calls "hints" is merely a rectangle around the text box. Hints can be turned on globally in the config file, using the `set` method, or in an individual text method. These are there merely for prototyping and are not intended for production. Additionally, these are not to be conflated with "rendering hints" that Pango and Cairo mention in their documentation.
236
+
237
+ ###Extents
238
+
239
+ Sometimes you want size things based on the size of your rendered text. For example, drawing a rectangle around card's title such that the rectangle perfectly fits. Squib returns the final rendered size of the text so you can work with it afterward. It's an array of hashes that correspond to each card. The output looks like this:
240
+
241
+ ```ruby
242
+ Squib::Deck.new(cards: 2) do
243
+ extents = text(str: ['Hello', 'World!'])
244
+ p extents
245
+ end
246
+ ```
247
+ Will output:
248
+ ```
249
+ [{:width=>109, :height=>55}, {:width=>142, :height=>55}] # Hello was 109 pixels wide, World 142 pixels
250
+ ```
251
+
252
+ ###Embedding Images
253
+
254
+ Squib can embed icons into the flow of text. To do this, you need to define text keys for Squib to look for, and then the corresponding files. The object given to the block is a [TextEmbed](docs/Squib/TextEmbed), which supports PNG and SVG. Here's a minimal example:
255
+
256
+ ```ruby
257
+ text(str: 'Gain 1 :health:') do |embed|
258
+ embed.svg key: ':health:', file: 'heart.svg'
259
+ end
260
+ ```
261
+
262
+ ###Markup
263
+
264
+ If you want to do specialized formatting within a given string, Squib has lots of options. By setting `markup: true`, you enable tons of text processing. This includes:
265
+
266
+ * Pango Markup. This is an HTML-like formatting language that specifies formatting inside your string. Pango Markup essentially supports any formatting option, but on a letter-by-letter basis. Such as: font options, letter spacing, gravity, color, etc. See the [Pango docs](https://developer.gnome.org/pango/stable/PangoMarkupFormat.html) for details.
267
+ * Quotes are converted to their curly counterparts where appropriate (i.e. &ldquo;smart quotes&rdquo; instead of "straight quotes").
268
+ * Apostraphes are converted to curly as well.
269
+ * LaTeX-style quotes are explicitly converted (<tt>``like this''</tt>)
270
+ * Em-dash and en-dash are converted with triple and double-dashes respectively (<tt>--</tt> is an en-dash, and <tt>---</tt> becomes an em-dash.)
271
+ * Ellipses can be specified with <tt>...</tt>. Note that this is entirely different from the `ellipsize` option (which determines what to do with overflowing text).
272
+
273
+ A few notes:
274
+ * Smart quoting assumes the UTF-8 character set.
275
+ * Pango markup uses an XML/HTML-ish processor. Some characters require HTML-entity escaping (e.g. `&amp;` for `&')
276
+
277
+ ### Text Sample
278
+ ```yaml
279
+ lsquote: "\u2018" #note that Yaml wants double quotes here to use escape chars
280
+ rsquote: "\u2019"
281
+ ldquote: "\u201C"
282
+ rdquote: "\u201D"
283
+ em_dash: "\u2014"
284
+ en_dash: "\u2013"
285
+ ellipsis: "\u2026"
286
+ ```
287
+
288
+ You can also disable the auto-quoting mechanism by setting `smart_quotes: false` in your config. Explicit replacements will still be performed.
289
+
290
+ ### Text Samples
291
+
292
+ Examples of all of the above are crammed into the `text_options.rb` sample [found here](https://github.com/andymeneely/squib/tree/master/samples/text_options.rb).
293
+
294
+ {include:file:samples/text_options.rb}
295
+
296
+ The `embed_text.rb` sample has more examples of embedding text, which can be [found here](https://github.com/andymeneely/squib/tree/master/samples/embed_text.rb).
297
+
298
+ {include:file:samples/embed_text.rb}
299
+
300
+ The `config_text_markup.rb` sample demonstrates how quoting can be configured, [found here](https://github.com/andymeneely/squib/tree/master/samples/config_text_markup.rb)
301
+
302
+ {include:file:samples/config_text_markup.rb}
303
+
304
+
305
+ ## Custom Layouts
306
+
307
+ Working with x-y coordinates all the time can be tiresome, and ideally everything in a game prototype should be data-driven and easily changed. For this, many Squib methods allow for a `layout` to be set. In essence, layouts are a way of setting default values for any argument given to the command.
308
+
309
+ To use a layout, set the `layout:` option on a `Deck.new` command to point to a YAML file. Any command that allows a `layout` option can be set with a Ruby symbol or String, and the command will then load the specified `x`, `y`, `width`, and `height`. The individual command can also override these options.
310
+
311
+ Instead of this:
312
+ ```ruby
313
+ # deck.rb
314
+ Squib::Deck.new(layout: 'custom-layout.yml') do
315
+ rect x: 75, y: 75, width: 675, height: 975
316
+ end
317
+ ```
318
+
319
+ You can put your logic in the layout file and reference them:
320
+ ```yaml
321
+ # custom-layout.yml
322
+ frame:
323
+ x: 75
324
+ y: 75
325
+ width: 975
326
+ height: 675
327
+ ```
328
+ Then your script looks like this:
329
+ ```ruby
330
+ # deck.rb
331
+ Squib::Deck.new(layout: 'custom-layout.yml') do
332
+ rect layout: 'frame'
333
+ end
334
+ ```
335
+ The goal is to make your Ruby code more separate data from logic, which in turn makes your code more readable and maintainable. With `extends` (see below), layouts become even more powerful in keeping you from repeating yourself.
336
+
337
+ Note: YAML is very finnicky about not allowing tab characters. Use two spaces for indentation instead. If you get a `Psych` syntax error, this is likely the culprit. Indendation is also strongly enforced in Yaml too. See the [Yaml docs](http://www.yaml.org/YAML_for_ruby.html).
338
+
339
+ ### Order of Precedence
340
+
341
+ Layouts will override Squib's system defaults, but are overriden by anything specified in the command itself. Thus, the order of precedence looks like this:
342
+
343
+ * Use what the command specified
344
+ * If anything was not yet specified, use what was given in a layout (if a layout was specified in the command and the file was given to the Deck)
345
+ * If still anything was not yet specified, use what was given in Squib's defaults.
346
+
347
+ ### Special key: `extends`
348
+
349
+ Squib provides a way of reusing layouts with the special `extends` key. When defining an `extends` key, we can merge in another key and modify data coming in if we want to. This allows us to do things like place text next to an icon and be able to move them with each other. Like this:
350
+
351
+ ```yaml
352
+ # If we change the xy of attack, we move defend too!
353
+ attack:
354
+ x: 100
355
+ y: 100
356
+ radius: 100
357
+ defend:
358
+ extends: attack
359
+ x: += 50
360
+ #defend now is {:x => 150, :y => 100}
361
+ ```
362
+
363
+ If you want to extend multiple parents, it looks like this:
364
+
365
+ ```yaml
366
+ socrates:
367
+ x: 100
368
+ plato:
369
+ y: 200
370
+ aristotle:
371
+ extends:
372
+ - socrates
373
+ - plato
374
+ x: += 50
375
+ ```
376
+ If multiple keys override the same keys in a parent, the later ("younger") child takes precedent.
377
+
378
+ Note that extends keys are similar to Yaml's ["merge keys"](http://www.yaml.org/YAML_for_ruby.html#merge_key). With merge keys, you can define base styles in one entry, then include those keys elsewhere. For example:
379
+
380
+ ```yaml
381
+ icon: &icon
382
+ width: 50
383
+ height: 50
384
+ icon_left
385
+ <<: *icon
386
+ x: 100
387
+ # The layout for icon_left will have the width/height from icon!
388
+ ```
389
+
390
+ If you use both `extends` and Yaml merge keys, the Yaml merge keys are processed first, then extends. For clarity, however, you're probably just better off using `extends` exclusively.
391
+
392
+ ### Multiple layout files
393
+
394
+ Squib also supports the combination of multiple layout files. If you provide an `Array` of files then Squib will merge them sequentially. Colliding keys will be completely re-defined by the later file. Extends is processed after _each file_. Here's a complex example:
395
+
396
+ ```yaml
397
+ # load order: a.yml, b.yml
398
+
399
+ ##############
400
+ # file a.yml #
401
+ ##############
402
+ grandparent:
403
+ x: 100
404
+ parent_a:
405
+ extends: grandparent
406
+ x: += 10 # evaluates to 110
407
+ parent_b:
408
+ extends: grandparent
409
+ x: += 20 # evaluates to 120
410
+
411
+ ##############
412
+ # file b.yml #
413
+ ##############
414
+ child_a:
415
+ extends: parent_a # i.e. extends a layout in a separate file
416
+ x: += 3 # evaluates to 113 (i.e 110 + 3)
417
+ parent_b: # redefined
418
+ extends: grandparent
419
+ x: += 30 # evaluates to 130 (i.e. 100 + 30)
420
+ child_b:
421
+ extends: parent_b
422
+ x: += 3 # evaluates to 133 (i.e. 130 + 3)
423
+ ```
424
+
425
+ This can be helpful for:
426
+ * Creating a base layout for structure, and one for color (for easier color/black-and-white switching)
427
+ * Sharing base layouts with other designers
428
+
429
+ YAML merge keys are NOT supported across multiple files - use `extends` instead.
430
+
431
+ ### Built-in Layout Files
432
+
433
+ Why mess with x-y coordinates when you're first prototyping your game?!?!? Just use a built-in layout to get your game to the table as quickly as possible.
434
+
435
+ If your layout file is not found in the current directory, Squib will search for its own set of layout files. The latest the development version of these can be found [on GitHub](https://github.com/andymeneely/squib/tree/master/lib/squib/layouts). The `layouts_builtin.rb` sample (found [here](https://github.com/andymeneely/squib/tree/master/samples/)) demonstrate built-in layouts based on popular games (e.g. `fantasy.yml` and `economy.yml`)
436
+
437
+ Contributions in this area are particularly welcome!
438
+
439
+ ### Layout Sample
440
+ This sample demonstrates many different ways of using and combining layouts. This is the `layouts.rb` sample found [here](https://github.com/andymeneely/squib/tree/master/samples/)
441
+
442
+ {include:file:samples/layouts.rb}
443
+
444
+ ## Backends: Raster vs. Vector
445
+ Under the hood, Cairo has the ability to support a variety of surfaces to draw on, including both raster images stored in memory and vectors stored in SVG files. Thus, Squib supports the ability to handle both. They are options in the configuration file `backend: memory` or `backend: svg`.
446
+
447
+ If you save to a PDF then the backend will determine how your cards are saved too. For `memory`, the PDF will be filled with compressed raster images and be a larger file (yet it will still print at high quality... see discussion below). For SVG backends, PDFs will be smaller. If you have your deck backed by SVG, then the cards are auto-saved, so there is no `save_svg` in Squib. (Technically, the operations are stored and then flushed to the SVG file at the very end.)
448
+
449
+ There are trade-offs that one should consider here.
450
+
451
+ * _Print quality is **higher** for raster images_. This seems counterintuitive at first, but consider where Squib sits in your workflow. It's the final assembly line for your cards before they get printed. Cairo puts _a ton_ of work into rendering each pixel perfectly when it works with raster images. Printers, on the other hand, don't think in vectors and will render your paths in their own memory with their own embedded libraries without putting a lot of work into antialiasing and various other graphical esoterica. You may notice that print-on-demand companies such as The Game Crafter [only accept raster file types](https://www.thegamecrafter.com/help/supported-file-types), because they don't want their customers complaining about printers not rendering vectors with enough care.
452
+ * _PDFs are **smaller** for SVG back ends_. If file size is a limitation for you, and it can be for some printers or internet forums, then an SVG back end for vectorized PDFs is the way to go.
453
+ * _Squib is **greedy** with memory_. While I've tested Squib with big decks on older computers, the `memory` backend is quite greedy with RAM. If memory is at a premium for you, switching to SVG might help.
454
+
455
+ Note: you can still load PNGs into an SVG-backed deck and load SVGs into a memory-backed deck. To me, the sweet spot is to keep all of my icons, text, and other stuff in vector form for infinite scaling and then render them all to pixels with Squib.
456
+
457
+ Fortunately, switching backends in Squib should be as trivial as changing the setting in the config file. So go ahead and experiment with both and see what works for you. See below for how the configuration options work.
458
+
459
+ ## Configuration File
460
+
461
+ Squib supports various configuration properties that can be specified in an external file. The `config:` option in `Deck.new` can specify an optional configuration file in YML format. The properties there are intended to be immutable for the life of the Deck. The options include:
462
+
463
+ * `progress_bars` (Boolean, default: false). When set to `true`, long-running operations will show a progress bar on the command line.
464
+ * `hint` (ColorString, default: off). Text hints are used to show the boundaries of text boxes. Can be enabled/disabled for individual commands, or set globally with the `set` command. This setting is overriden by `set` and individual commands.
465
+ * `custom_colors` (Hash of Colors, default: {}). Defines globally-available colors available to the deck that can be specified in commands.
466
+ * `antialias` (`fast, good, best, none, gray, subpixel`, default: best). Set the algorithm that Cairo will use for antialiasing. Using our benchmarks on large decks, `best` is only ~10% slower anyway. For more info see the [Cairo docs](http://www.cairographics.org/manual/cairo-cairo-t.html#cairo-antialias-t).
467
+ * `backend` (`svg` or `memory`, default: `memory`). Defines how Cairo will store the operations. Memory is recommended for higher quality rendering.
468
+ * `prefix` (default: `card_`). When using an SVG backend, cards are auto-saved with this prefix and `"%02d"` numbering format.
469
+ * `warn_ellipsize` (default: true). Warn when text is ellipsized
470
+ * `warn_png_scale` (default: true). Warn when a PNG file is upscaled
471
+
472
+ For debugging/sanity purposes, if you want to make sure your configuration options are parsed correclty, the above options are also available as methods within Squib::Deck, for example:
473
+
474
+ ```ruby
475
+ Squib::Deck.new do
476
+ puts backend # prints 'memory' by default
477
+ end
478
+ ```
479
+
480
+ The following sample demonstrates the config file, found [here](https://github.com/andymeneely/squib/tree/master/samples/)
481
+
482
+ {include:file:samples/custom_config.rb}
483
+
484
+ ## Importing from Excel and CSV
485
+
486
+ Squib supports importing data from `xlsx` files and `csv` files. These methods are column-based, which means that they assume you have a header row in your table, and that header row will define the column. Squib will return a `Hash` of `Arrays` correspoding to each row. Warnings are thrown on things like duplicate columns. See the `excel.rb` and the `csv_import.rb` sample found [here](https://github.com/andymeneely/squib/tree/master/samples/).
487
+
488
+ {include:file:samples/excel.rb}
489
+
490
+ Of course, you can always import your game data other ways using just Ruby. There's nothing special about Squib's methods other than their convenience.
491
+
492
+ ###Quantity Explosion
493
+
494
+ If you want more than one copy of a card, then have a column called `Qty` and fill it with counts. Squib's `xlsx` and `csv` methods will automatically expand those rows according to those counts. You can also customize that "Qty" to anything you like by setting the `explode` option (e.g. `explode: 'Quantity'`). See the `excel.rb` and the `csv_import.rb` samples found [here](https://github.com/andymeneely/squib/tree/master/samples/) for an example.
495
+
496
+ ## Making Squib Verbose
497
+
498
+ By default, Squib's logger is set to WARN, but more fine-grained logging is embedded in the code. To set the logger, just put this at the top of your script:
499
+
500
+ ```ruby
501
+ Squib::logger.level = Logger::INFO
502
+ ```
503
+
504
+ If you REALLY want to see tons of output, you can also set DEBUG, but that's not intended for general consumption.
505
+
506
+ # "Best" Practices
507
+
508
+ Here's a collection of workflow tips and code snippets that will hopefully improve your Squibbing. Contributions are welcome!
509
+
510
+ ## Staying DRY
511
+
512
+ Squib tries to keep you DRY (Don't Repeat Yourself) with the following features:
513
+
514
+ * Custom layouts allow you to specify various arguments in a separate file. This is great for x-y coordinates and alignment properties that would otherwise clutter up perfectly readable code. Squib goes even further and has a special "extends" that works especially well for grouped-together styles.
515
+ * Flexible ranges and array handling: the `range` parameter in Squib is very flexible, meaning that one `text` command can specify different text in different fonts, styles, colors, etc. for each card. If you find yourself doing multiple `text` command for the same field across different ranges of cards, there's probably a better way to condense.
516
+ * Custom colors keep you from hardcoding magic color strings everywhere. Custom colors go into `config.yml` file.
517
+ * Plus, you know, Ruby.
518
+
519
+ ## Get to know Ruby's Array and Enumerable
520
+
521
+ Don't know Ruby? Welcome! We are so happy that Squib is your excuse to learn Ruby.
522
+
523
+ Ruby has a *very* rich library for all of its built-in data types, especially [Array](http://ruby-doc.org/core-2.2.0/Array.html), and it's broader module [Enumerable](http://ruby-doc.org/core-2.2.0/Enumerable.html). Since Squib primarily takes in arrays into most of its fields, getting to know these methods will help you out enormously:
524
+
525
+ * [Array#each](http://ruby-doc.org/core-2.2.0/Array.html#method-i-each) - do something on each element of the array (Ruby folks seldom use for-loops)
526
+ * [Array#map](http://ruby-doc.org/core-2.2.0/Array.html#method-i-map) - do something on each element of an array and put it into a new array
527
+ * [Array#select](http://ruby-doc.org/core-2.2.0/Array.html#method-i-select) - select a subset of an array
528
+ * [Enumerable#each_with_index](http://ruby-doc.org/core-2.2.0/Enumerable.html#method-i-each_with_index) - do something to each element, also being aware of the index
529
+ * [Array#zip](http://ruby-doc.org/core-2.2.0/Enumerable.html#method-i-zip) - combine two arrays, element by element
530
+
531
+ ## Source control
532
+
533
+ You are using source control, right??
534
+
535
+ By default, Squib assumes Git. But it's not dogmatic about it. Tracking your progress, backing up, sharing data, topic branches, release management, and reverting into history are just some of the many, many useful things you can do with source control. For me, I tend to ignore any auto-generated files in my output folder, but version control everything else. I also try to keep my graphics vector files, so the files stay small. Version control is intended for source code, so large binary files that change often probably should not get checked in unless absolutely necessary. I tend to keep big raster graphics files (e.g. from Gimp) in cloud storage or elsewhere.
536
+
537
+ ## SublimeText
538
+
539
+ Using SublimeText? I like you already. I've written up some Squib snippets to ease remembering Squib commands. It's called `Squib Snippets` on Package Control. Compatible with SublimeText 3. Source code is also [on Github](https://github.com/andymeneely/sublime-squib) (contributions welcome!). Check it out:
540
+
541
+ ![Sublime Squib Snippets](https://raw.githubusercontent.com/andymeneely/squib/screencasts/sublime-squib-snippets.gif)
542
+
543
+ ## Decks with multiple orientations or sizes
544
+
545
+ If you want to make a deck that has some portrait and some landscape cards, I recommend you use multiple `Squib::Deck`s. The pixel size of a given card is designed to not change thorughout the life of a `Squib::Deck`. To work with landscape cards, there is a `rotate` option on `save_png` so you can render your print-on-demand PNGs in portrait but keep everything else oriented toward landscape. The following example demonstrates how to do this, found [here](https://github.com/andymeneely/squib/tree/master/samples/portrait-landscape.rb).
546
+
547
+ {include:file:samples/portrait-landscape.rb}
548
+
549
+ ## Rakefile
550
+
551
+ When you run `squib new`, you are given a basic Rakefile. At this stage of Squib, it's basically just a shortcut for `ruby deck.rb`. But, even in this simple form this Rakefile has some advantages:
552
+
553
+ * If you're in a subdirectory at the time, `rake` will simply traverse up and `cd` to the proper directory so you don't get rogue `_output` directories
554
+ * If you find yourself building multiple decks, you can make your own tasks for each one individually, or all (e.g. `rake marketing`)
555
+ * Don't need the `require squib` at the top of your code (although that breaks `ruby deck.rb`, so that's probably a bad idea)
556
+
557
+ ## Using Google Sheets
558
+
559
+ We don't officially support Google Sheets ([yet](https://github.com/andymeneely/squib/issues/49)), but [this Gist](https://gist.github.com/pickfifteen/aeee73ec2ce162b0aee8) might be helpful in automatically exporting the CSV.
560
+
561
+ ## Combining Multiple Columns
562
+
563
+ Say you have multiple columns in your Excel sheet that need to be combined into one text field on your card. Consider using `zip` in conjunction with `map`.
564
+
565
+ ```ruby
566
+ data['BuyText'] = data['BuyAmount'].zip(data['BuyType']).map do |amt, type|
567
+ "You may purchase #{amt} #{type}" #e.g. You may purchase 1 Wood.
568
+ end
569
+
570
+ data['Cost'] = data['Action Cost'].zip(data['Card Cost']).map do |ac, cc|
571
+ ':action:' * ac.to_i + ":card#{cc}:"
572
+ end
573
+ ```
574
+
575
+ Second example adapted from [this conversation](https://github.com/andymeneely/squib/issues/90)
576
+
577
+ # Get Involved
578
+
579
+ Squib is an open source tool, so I welcome participation. Squib is currently in pre-release alpha, so the API is still maturing. I do change my mind about the names and meaning of things at this stage. I will document these changes as best as I can.
580
+
581
+ I also highly recommend upgrading to new versions of Squib every chance you get (using Bundler). You can watch for new upgrades by following the RubyGems [RSS](https://rubygems.org/gems/squib/versions.atom), or by watching the project on GitHub.
582
+
583
+ For bugs and feature requests, feel free to [file a bug or feature request](https://github.com/andymeneely/squib/issues). A minimal code example along with your OS and Ruby details would be ideal.
584
+
585
+ ## New to Programming?
586
+
587
+ I often hear statements like "I'm not a programmer, but I want to use Squib." If you want to use Squib, then maybe you really were a programmer all along :)
588
+
589
+ Squib is a Ruby library. To learn Squib, you will need to learn Ruby. There is no getting around that fact. Don't fight it, embrace it.
590
+
591
+ Fortunately, Ruby is wonderfully rich in features and very expressive in its syntax. Ruby has a vibrant, friendly community (much like tabletop game designers!). Ruby is the language of choice for many new programmers, including many universities. Plus, learning how to code is ubiquitous on the Internet.
592
+
593
+ Doubly fortunately, Squib doesn't require tons of Ruby-fu to get going either. The main things you'll need to know are:
594
+ * Working on the command line
595
+ * Ruby Arrays, so that the `range` parameter makes more sense
596
+ * Strings, variables, and symbols
597
+ * If you are using Excel or CSV, then Ruby hashes are worth a glance.
598
+ * Working iteratively: making small edits and run your code frequently (every few minutes)
599
+
600
+ Anything related to Ruby on Rails is not necessary to learn for Squib. Rails is a heavyweight framework for web development (awesome in its own way, but not relevant to learning Ruby). Squib is about scripting.
601
+
602
+ ## Get Help
603
+
604
+ There are lots of people using Squib already. If you've gone through the [samples](https://github.com/andymeneely/squib/tree/master/samples) and still have questions, here are some other places to get help.
605
+
606
+ * Our [thread on BoardGameGeek](http://boardgamegeek.com/thread/1293453) is quite active and informal (if a bit unstructured).
607
+ * [StackOverflow](http://stackoverflow.com/questions/ask?tags=ruby squib) with the tag "ruby" and "squib" will get you answers quickly and a great way to document questions for future Squibbers.
608
+
609
+ If you email me directly I'll probably ask you to post your question publicly so we can document answers for future Googling Squibbers.
610
+
611
+ Please use GitHub issues for bugs and feature requests.
612
+
613
+ ## Give Help
614
+
615
+ Let's help each other out! Even if you're relatively new, there's probably some question out there that you can help answer. Here's how to help:
616
+
617
+ * Subscribe to our thread on BoardGameGeek (see above for link)
618
+ * Subscribe to alerts from Stackoverflow for the tags "squib" and "ruby"
619
+ * Post snippets of your code using GitHub gists
620
+ * Write a how-to tutorial and post it on [our wiki](https://github.com/andymeneely/squib/wiki)
621
+
622
+ ## Testing Pre-Builds
623
+
624
+ Testers needed!! If you want to test new features as I develop them, or make sure I didn't break your code, you can always point your Gemfile to the repository and follow what I'm doing there. Your Gemfile specification looks like this:
625
+
626
+ ```ruby
627
+ gem 'squib', git: 'git://github.com/andymeneely/squib', branch: 'dev'
628
+ ```
629
+ * The `dev` branch is where I am working on features in-process. I have not done much regression testing at this point, but would love testing feedback nonetheless.
630
+ * The `master` branch is where I consider features and bug that are done and tested, but not released yet.
631
+
632
+ ## Contributing
633
+
634
+ If you want your code integrated:
635
+
636
+ 1. Fork the git repository ( https://github.com/[my-github-username]/squib/fork )
637
+ 2. Create your feature branch (`git checkout -b my-new-feature`)
638
+ 3. Commit your changes (`git commit -am 'Add some feature'`)
639
+ 4. Push to the branch (`git push origin my-new-feature`)
640
+ 5. Create a new Pull Request
641
+
642
+ Be sure to run the unit tests and packaging with just `rake`. Also, you can check that the samples render properly with `rake sanity`.
643
+
644
+ # What's up the with the name?
645
+
646
+ Truthfully, I just thought it was a cool, simple word that was not used much in the Ruby community nor the board game community. But, now that I've committed to the name, I've realized that:
647
+
648
+ * Squibs are small explosive devices, much like Squib "explodes" your rules into a playable game
649
+ * Squibs are often used in heist movies, leading to a sudden plot twist that often resembles the twists of good tabletop game
650
+ * Squibs are also part of the Harry Potter world - they are people who are non-magical but wizard-born. Squib is aware of wizarding magic and comes from that heritage, but it's not magical itself.