2 * drawing.c: Intermediary between the drawing interface as
3 * presented to the back end, and that implemented by the front
6 * Mostly just looks up calls in a vtable and passes them through
7 * unchanged. However, on the printing side it tracks print colours
8 * so the front end API doesn't have to.
12 * - I'd _like_ to do automatic draw_updates, but it's a pain for
13 * draw_text in particular. I'd have to invent a front end API
14 * which retrieved the text bounds.
15 * + that might allow me to do the alignment centrally as well?
16 * * perhaps not, because PS can't return this information,
17 * so there would have to be a special case for it.
18 * + however, that at least doesn't stand in the way of using
19 * the text bounds for draw_update, because PS doesn't need
20 * draw_update since it's printing-only. Any _interactive_
21 * drawing API couldn't get away with refusing to tell you
22 * what parts of the screen a text draw had covered, because
23 * you would inevitably need to erase it later on.
36 int hatch_when; /* 0=never 1=only-in-b&w 2=always */
42 const drawing_api *api;
44 struct print_colour *colours;
45 int ncolours, coloursize;
47 /* `me' is only used in status_bar(), so print-oriented instances of
48 * this may set it to NULL. */
53 drawing *drawing_new(const drawing_api *api, midend *me, void *handle)
55 drawing *dr = snew(drawing);
59 dr->ncolours = dr->coloursize = 0;
62 dr->laststatus = NULL;
66 void drawing_free(drawing *dr)
68 sfree(dr->laststatus);
73 void draw_text(drawing *dr, int x, int y, int fonttype, int fontsize,
74 int align, int colour, char *text)
76 dr->api->draw_text(dr->handle, x, y, fonttype, fontsize, align,
80 void draw_rect(drawing *dr, int x, int y, int w, int h, int colour)
82 dr->api->draw_rect(dr->handle, x, y, w, h, colour);
85 void draw_line(drawing *dr, int x1, int y1, int x2, int y2, int colour)
87 dr->api->draw_line(dr->handle, x1, y1, x2, y2, colour);
90 void draw_polygon(drawing *dr, int *coords, int npoints,
91 int fillcolour, int outlinecolour)
93 dr->api->draw_polygon(dr->handle, coords, npoints, fillcolour,
97 void draw_circle(drawing *dr, int cx, int cy, int radius,
98 int fillcolour, int outlinecolour)
100 dr->api->draw_circle(dr->handle, cx, cy, radius, fillcolour,
104 void draw_update(drawing *dr, int x, int y, int w, int h)
106 if (dr->api->draw_update)
107 dr->api->draw_update(dr->handle, x, y, w, h);
110 void clip(drawing *dr, int x, int y, int w, int h)
112 dr->api->clip(dr->handle, x, y, w, h);
115 void unclip(drawing *dr)
117 dr->api->unclip(dr->handle);
120 void start_draw(drawing *dr)
122 dr->api->start_draw(dr->handle);
125 void end_draw(drawing *dr)
127 dr->api->end_draw(dr->handle);
130 void status_bar(drawing *dr, char *text)
134 if (!dr->api->status_bar)
139 rewritten = midend_rewrite_statusbar(dr->me, text);
140 if (!dr->laststatus || strcmp(rewritten, dr->laststatus)) {
141 dr->api->status_bar(dr->handle, rewritten);
142 sfree(dr->laststatus);
143 dr->laststatus = rewritten;
149 blitter *blitter_new(drawing *dr, int w, int h)
151 return dr->api->blitter_new(dr->handle, w, h);
154 void blitter_free(drawing *dr, blitter *bl)
156 dr->api->blitter_free(dr->handle, bl);
159 void blitter_save(drawing *dr, blitter *bl, int x, int y)
161 dr->api->blitter_save(dr->handle, bl, x, y);
164 void blitter_load(drawing *dr, blitter *bl, int x, int y)
166 dr->api->blitter_load(dr->handle, bl, x, y);
169 void print_begin_doc(drawing *dr, int pages)
171 dr->api->begin_doc(dr->handle, pages);
174 void print_begin_page(drawing *dr, int number)
176 dr->api->begin_page(dr->handle, number);
179 void print_begin_puzzle(drawing *dr, float xm, float xc,
180 float ym, float yc, int pw, int ph, float wmm,
185 dr->api->begin_puzzle(dr->handle, xm, xc, ym, yc, pw, ph, wmm);
188 void print_end_puzzle(drawing *dr)
190 dr->api->end_puzzle(dr->handle);
194 void print_end_page(drawing *dr, int number)
196 dr->api->end_page(dr->handle, number);
199 void print_end_doc(drawing *dr)
201 dr->api->end_doc(dr->handle);
204 void print_get_colour(drawing *dr, int colour, int printing_in_colour,
205 int *hatch, float *r, float *g, float *b)
207 assert(colour >= 0 && colour < dr->ncolours);
208 if (dr->colours[colour].hatch_when == 2 ||
209 (dr->colours[colour].hatch_when == 1 && !printing_in_colour)) {
210 *hatch = dr->colours[colour].hatch;
213 if (printing_in_colour) {
214 *r = dr->colours[colour].r;
215 *g = dr->colours[colour].g;
216 *b = dr->colours[colour].b;
218 *r = *g = *b = dr->colours[colour].grey;
223 static int print_generic_colour(drawing *dr, float r, float g, float b,
224 float grey, int hatch, int hatch_when)
226 if (dr->ncolours >= dr->coloursize) {
227 dr->coloursize = dr->ncolours + 16;
228 dr->colours = sresize(dr->colours, dr->coloursize,
229 struct print_colour);
231 dr->colours[dr->ncolours].hatch = hatch;
232 dr->colours[dr->ncolours].hatch_when = hatch_when;
233 dr->colours[dr->ncolours].r = r;
234 dr->colours[dr->ncolours].g = g;
235 dr->colours[dr->ncolours].b = b;
236 dr->colours[dr->ncolours].grey = grey;
237 return dr->ncolours++;
240 int print_mono_colour(drawing *dr, int grey)
242 return print_generic_colour(dr, grey, grey, grey, grey, -1, 0);
245 int print_grey_colour(drawing *dr, float grey)
247 return print_generic_colour(dr, grey, grey, grey, grey, -1, 0);
250 int print_hatched_colour(drawing *dr, int hatch)
252 return print_generic_colour(dr, 0, 0, 0, 0, hatch, 2);
255 int print_rgb_mono_colour(drawing *dr, float r, float g, float b, int grey)
257 return print_generic_colour(dr, r, g, b, grey, -1, 0);
260 int print_rgb_grey_colour(drawing *dr, float r, float g, float b, float grey)
262 return print_generic_colour(dr, r, g, b, grey, -1, 0);
265 int print_rgb_hatched_colour(drawing *dr, float r, float g, float b, int hatch)
267 return print_generic_colour(dr, r, g, b, 0, hatch, 1);
270 void print_line_width(drawing *dr, int width)
273 * I don't think it's entirely sensible to have line widths be
274 * entirely relative to the puzzle size; there is a point
275 * beyond which lines are just _stupidly_ thick. On the other
276 * hand, absolute line widths aren't particularly nice either
277 * because they start to feel a bit feeble at really large
280 * My experimental answer is to scale line widths as the
281 * _square root_ of the main puzzle scale. Double the puzzle
282 * size, and the line width multiplies by 1.4.
284 dr->api->line_width(dr->handle, (float)sqrt(dr->scale) * width);