Timeline for Is there a way to make the tick marks larger?
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 26, 2012 at 13:44 | comment | added | Szabolcs | I wrote another answer where I recommend custom ticks. As something related: I'd really like to have a meta question where people can post any package they use (packages they actually use in practice!!) as answers, and others who also use them could upvote those posts. It would be good for sharing one's own packages as well. Because of the voting and because of the requirement to vote for packages you use (not ones you found), this would be a completely different resource from MathSource and IMO quite useful. Thoughts? (In chat.) | |
| May 26, 2012 at 13:31 | comment | added | J. M.'s missing motivation | In that case, I'll add a caveat to this answer later... | |
| May 26, 2012 at 13:30 | comment | added | Szabolcs | Unfortunately, at this point I think there is no way to fix this. There doesn't seem to be a completely reliable way to retrieve the automatically generated ticks (Ticks -> Automatic). The usual advice is to use the CustomTicks package (also part of LevelScheme) to automate generating reasonable ticks, then it's easy to transform the tick specification later. | |
| May 26, 2012 at 13:25 | comment | added | J. M.'s missing motivation | Crap, that was precisely the alternative I was going to pursue... :( it will take me a while to think of how to fix this. | |
| May 26, 2012 at 13:23 | comment | added | Szabolcs | There's also something wrong with FullGraphics: it will mess up both ticks and grid lines. I think the reason is that graphics are rendered by the Front End while FullGraphics is just an approximation of this rendering, done by the kernel. You can even read the source of FullGraphics, and find many relics from pre v6 times. What It may be that AbsoluteOptions is broken for the same reason. Why I don't understand is: why would it be necessary that ticks are generated by the front end, not the kernel. One guess is that tick spacing should depend on font sizes, which is know only to the FE | |
| May 26, 2012 at 13:20 | comment | added | Szabolcs | Still won't do what it's supposed to. Yes, you are right that there is something wrong with AbsoluteOptions. In 3D it won't even return a tick-list, and in 3D tick sizing is simply broken! When you increase the ImageResolution in Rasterize, ticks don't scale linearly (they scale according to some weird functions...) This prevents me from doing proper antialiasing by upscaling then downscaling. Note how the ticks become near-invisible in the antialiased version in my link. It's because of this, not because lines get thin. | |
| May 26, 2012 at 13:14 | comment | added | J. M.'s missing motivation | @Szabolcs: I can't test at the moment; could you try Block[{test = Plot[Sin[x], {x, 0, 2 Pi}]}, GraphicsRow[{test, Show[test, First[AbsoluteOptions[test, Ticks]]]}]] and see what comes up? | |
| May 26, 2012 at 13:12 | comment | added | J. M.'s missing motivation | Must be something screwy with AbsoluteOptions[]. (It wasn't this way before.) I assumed it would get exactly the tick styles used. I'll need to think slightly more about this. | |
| May 26, 2012 at 13:05 | comment | added | Szabolcs | But this increased the number of tick marks and changed how labels are formatted (6. instead of 6). :-( | |
| May 25, 2012 at 19:02 | history | answered | J. M.'s missing motivation | CC BY-SA 3.0 |