Suggestion for Rasterization to docs pgf-backend

[overdetermined]

As per discussion on issue:
#5983

[mdboom]

Attn: @pwuertz

[pwuertz]

This advice is universal for any kind of vector file format for any environment, i.e. it isn't exactly a problem specific to PGF. I don't object to adding it to the documentation, I'm just wondering if there is a suitable place upwards in the hierarchy to indicate matplotlibs selective rasterization solution for high geometry count in vector graphics.

On the other hand, TeX probably isn't particularly optimized for such situations, so if it breaks down magnitudes earlier than your typical SVG or PDF renderer please go ahead.

[QuLogic]

I believe the keyword arg is rasterized.

[efiring]

I agree with @pwuertz that this info should be highlighted more generally for the vector backends. Maybe it could become an entry in the FAQ, something like "how to make smaller, faster-rendering files in ps, pdf, pgf and svg formats". I'm not sure whether that is the best place. This ability of mpl to rasterize on a per-artist basis is an important feature that can make the difference between an excellent file and an unusable one.

[overdetermined]

@QuLogic good spot! I changed it accordingly. Even though i feel a little like I am commit-spamming at this point...
@efiring I have also included rasterized now in the artist properties in the artist tutorial. I may find more time tomorrow to peruse through the docs and find a good place for improvements.

Until now I was just using githubs editor to make the changes. To edit two files at once I actually downloaded the source; but as I am on holiday with a slow internet connection it took a while and it's getting late.

[QuLogic]

In that case, please be sure you configured your git client correctly (GitHub is not recognizing your email and associating it with your account, if that is important to you.) It would be best to get the name/email on the commits to be consistent.

Also, if you wish to squash the commits, then you may do a rebase.

[overdetermined]

@QuLogic, I'm pretty sure a rebase will not squash the commits.... a --squash commit would, but I think i'd just leave it at this to be honest. My two other options are changing the branch history: dunno what would happend to this thread, make a new branch with a single commit and a new pull request: seems too much effort for something minor.
Any idea why the travis build is failing?? It has failed on me on previous commits, but in configurations where i have made zero changes....

[jenshnielsen]

@overdetermined The travis failure is a random fluke in a test that depends on timing and is somewhat unstable

[WeatherGod]

The pull request tracks the branch, not the commits. So, squashing won't
cause problems with this thread. You wouldn't need to create a new branch
or pull request. We encourage the use of squashing (but we don't require
it), especially in situations where there are lots of marginal changes
whose history is irrelevant. For example, someone working on a feature to
improve text kerning might update some images multiple times until the
kerning is "just right". Afterwards, the squash would be requested because
the intermediate changes to the images are irrelevant and simply clutters
the final history.

In your case, I am meh on whether or not to squash your commits. It would
make the history cleaner, but don't knock yourself out on it.

On Wed, Feb 10, 2016 at 4:37 AM, Jens Hedegaard Nielsen <
notifications@github.com> wrote:

@overdetermined https://github.com/overdetermined The travis failure is
a random fluke in a test that depends on timing and is somewhat unstable

—
Reply to this email directly or view it on GitHub
#5984 (comment)
.

[overdetermined]

@WeatherGod Squashed the commits. @QuLogic you can indeed use rebase to squash the commits sorry for doubting you ;-). I used "git reset --soft HEAD~5" though.

[tacaswell]

For rst reasons I only half understand, using 2 __ for the link is safer. Ditto 3 lines down.

[tacaswell]

backported to v1.5.1-doc as 851f25c