This is lovely. When I see this, I don't think 'patterns', rather, 'hatches'.
Makes me wonder what the state of modern SVG is w.r.t. real-world units - something like this really makes SVG look useful for for technical drawing, but pixels are not the best unit to draw to...
Aren’t these textures already reusable? The constructed texture object (the result of textures.lines(), e.g.) can be called on as many selections as you like to reuse it.
I feel it’s a matter of taste, but one practical reason I prefer chaining to configuration objects is that you get a runtime error when you misspell a property, rather than it being silently ignored.
An initial config object would probably be ideal, and then you could have the chaining to supplement those values. You could have the initial method take in the config and use the values in that in place of the defaults. So
This is pretty cool. I made a really basic example, but in doing it, I could imagine playing around with having the colors or orientation change with the data as well. And it might make for cool transitions too. That obviously get way too complicated pretty quickly, but it'd be fun to see what you could come up with that might work.
Tufte points out 1 + 1 is 3 or more visually. The two lines create two elements, then the space is another, then the space on either is potentially another.
Interesting point of view. Choices of style apart, there are situations where textures are useful. Like for example the case faced by swayvil (see the comment), or when you need b/w printable images.
Another good reference is "Semiology of Graphics" of Jacques Bertin, he has a good opinion about textures.
"Semiology of Graphics" is a great book, but this was published in the 1960s when those graphs where drafted by hand and color printing was probably not an option.
I am ignorant as to what tools a draft-mans hand for shading then, but I am sure hatching would be easier than creating a fine range of halftone grays.
> Can optical art effects ever produce a better graphic? Bertin exhorts: “It is the designer’s duty to make the most of this variation; to obtain the resonance [of moiré vibration] without provoking an uncomfortable sensation: to flirt with ambiguity without succumbing to it.” But can statistical graphics successfully “flirt with ambiguity”? It is a clever idea, but no good examples are to be found. The key difficulty remains: moiré vibration is an undisciplined ambiguity, with an illusive, eye-straining quality that contaminates the entire graphic. It has no place in data graphical design.
Loving the retro look. But I'm not sure if patterns are as good as colors in communicating data. As soon as the data has even an ordinal scale, gradients or hues should work better.
Patterns are useful if it is intended to be printed (or for other b/w media). For good color prints or screen usage I agree, colors often can do a better job.
You are probably right if the data you're representing is scaled, but this sort of solution is fantastic for categorical data. Also, see other comments re: accessibility for colorblindness. Not necessarily a silver bullet, but possibly a solid solution in some circumstances.
All of our invoices and reports are built for the web and then converted on the fly to pdfs and emailed out to clients who prefer them that way. You lose the interactivity, which is a shame for some d3 reports, and you have to be a little careful (design for page breaks, test it as if it's a slightly fickle browser that you have to support, ensure that everything is visible without requiring interaction) but it keeps all of your development within the same tool stack and gives you web versions of them all for free.
Oh, I looked into it, but if you compare with LaTeX, its pretty simple, but we need references, and footnoes, and complex tables, so we would need an extended version, and preprocess it, and.. might as well use LaTeX.
This is lovely. I've hand-coded solutions before to show two variables by region simultaneously (e.g. voting patterns by socio-economic levels:http://imgur.com/ww1WV66). Colour and texture are nicely independent for showing this stuff.
In my opinion the "right" way for static things. Keeps the browser from computing, no need for the original data and libs. Of course being able to inspec other people's d3 code is fun on the other hand.
Thanks for the update! I was unaware of the power of geoJSON (also githubs neat mapping of them) and access to data from places such as gadm.org. Is that where you source the data?
Thank you for sharing this! Can't wait to use this soon :)
Slightly off topic but maybe some SVG expert can help me out with a quick question! Is there a way to identify and automatically recognize all numbers in an image.svg file?
What kind of numbers? Those appearing alone in attributes, such as <rect width='10' height='5'/>? Those appearing in path or polygon data are more complicated, as the syntax allows whitespace, commas, etc. as separators, but they're not needed in some cases. E.g.
M0-1.2.5-3
is perfectly valid (AFAIR, not sure about the decimal points now), but not really nice to parse or extract.
The main point would be what your use case is? If you just need to transform something, e.g. translate or scale a shape it's easier to put a group around it and apply a transform on that.
Makes me wonder what the state of modern SVG is w.r.t. real-world units - something like this really makes SVG look useful for for technical drawing, but pixels are not the best unit to draw to...