I used to have scale 1 2000 base-scale 1 1000 in my layout. That worked OK, but the symbols were very small and the text was microscopic. So I added code metapost fonts_setup(10,16,20,24,28) And that made the text a sensible size. I just changed base scale to read base-scale 1 2000 which makes the symbols a much more sensible size, but makes the text too big. My understanding of these two values is that scale sets the scale of the output (i.e how big the final PDF sheet is in map mode, or how many sheets in atlas mode) , whilst base-scale 'has the same effect as if the map printed in base-scale would be photreduced to the scale' (quote from thbook) But if it was photoreduced then the fonts and symbol size shouldn't change. So I am confused about how this should work. When would I ever want scale and base-scale to be different? Why does changing base-scale effect the size of symbols and text? On a related point I tried doing an atlas version with the defaults (i.e. 1:200) and get loads of 'number too big errors' from metafont. I can see why such a scale is a problem in map mode (page larger than PDF can manage), but in atlas mode the page size is limited to A4 (or whatever) - so why can I not print an atlas (with a lot of sheets) showing the system in high detail? Is it a fundamental problem of the way the PDFs are generated or can it be fixed? Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
On Thu, Aug 18, 2005 at 12:10:01AM +0100, Wookey wrote:
But if it was photoreduced then the fonts and symbol size shouldn't change.
If you printed the survey at 1:1000 and photoreduced it to 1:2000, the symbols and text would be halved in size by the photoreduction. Just printing at 1:2000 will give symbols and text twice as large as this, so changing base-scale from 1:1000 to 1:2000 should double the symbol and text sizes. And it sounds like it does for you... Cheers, Olly
+++ Olly Betts [05-08-18 10:13 +0100]:
On Thu, Aug 18, 2005 at 12:10:01AM +0100, Wookey wrote:
But if it was photoreduced then the fonts and symbol size shouldn't change.
If you printed the survey at 1:1000 and photoreduced it to 1:2000, the symbols and text would be halved in size by the photoreduction. Just printing at 1:2000 will give symbols and text twice as large as this, so changing base-scale from 1:1000 to 1:2000 should double the symbol and text sizes. And it sounds like it does for you...
That makes sense. Quite why I couldn't manage that logic last night I don't know. Putting that para in the thbook might allow confused people like myself to get their heads round it (as clearly the current text didn't quite do it for me). Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
On Thu, 18 Aug 2005 00:10:01 +0100, Wookey wrote
I used to have scale 1 2000 base-scale 1 1000
in my layout. That worked OK, but the symbols were very small and the text was microscopic.
They were printed in 1/2 size because of base-scale setting.
So I added code metapost fonts_setup(10,16,20,24,28)
And that made the text a sensible size.
I just changed base scale to read base-scale 1 2000
which makes the symbols a much more sensible size, but makes the text too big.
If the base-scale is equal the scale, it has no effect (such as 1:1 photocopy) . The text was large because of your fonts_setup setting.
My understanding of these two values is that scale sets the scale of the output (i.e how big the final PDF sheet is in map mode, or how many sheets in atlas mode) , whilst base-scale 'has the same effect as if the map printed in base-scale would be photreduced to the scale' (quote from thbook)
You may forget the base-scale if the default settings work well. We introduced the base-scale to make it possible to do simple adjustments to the size of symbols used without the need of metapost programming (e.g. when symbols appear too big in the 1:400 scale, but OK in 1:200 scale, it's enough to set base-scale 1 200 and scale 1 400 and I get map in 1:400 scale with symbols proportionally as large as on 1:200 map)
But if it was photoreduced then the fonts and symbol size shouldn't change.
I think photocopy 1:2 changes everything to be 1/2 smaller
So I am confused about how this should work. When would I ever want scale and base-scale to be different? Why does changing base-scale effect the size of symbols and text?
See above. If therion gives you suitable symbol sizes, use only scale setting. If not, experiment with base-scale or redefine metapost.
On a related point I tried doing an atlas version with the defaults (i.e. 1:200) and get loads of 'number too big errors' from metafont.
I can see why such a scale is a problem in map mode (page larger than PDF can manage), but in atlas mode the page size is limited to A4 (or whatever) - so why can I not print an atlas (with a lot of sheets) showing the system in high detail? Is it a fundamental problem of the way the PDFs are generated or can it be fixed?
An additional limitation is the size of a picture, which can metapost process -- it's about 2.8 m. Each scrap is processed separately in one picture, so it means, that each scrap must be smaller than 2.8 * 2.8 m _in the output scale_. I don't think it's a big issue unless you try to draw the whole cave in one scrap. (At 1:100 scale a scrap can contain 280*280 m section of the cave). Atlas size (and SVG map size) is unlimited. Martin
+++ Martin Budaj [05-08-18 11:23 +0200]:
On Thu, 18 Aug 2005 00:10:01 +0100, Wookey wrote
I can see why such a scale is a problem in map mode (page larger than PDF can manage), but in atlas mode the page size is limited to A4 (or whatever) - so why can I not print an atlas (with a lot of sheets) showing the system in high detail? Is it a fundamental problem of the way the PDFs are generated or can it be fixed?
An additional limitation is the size of a picture, which can metapost process -- it's about 2.8 m. Each scrap is processed separately in one picture, so it means, that each scrap must be smaller than 2.8 * 2.8 m _in the output scale_. I don't think it's a big issue unless you try to draw the whole cave in one scrap. (At 1:100 scale a scrap can contain 280*280 m section of the cave).
Hmm, so as it goes wrong with the default (scale 1:200) that suggets I have one scrap which is >560m long. I don't think I do have anything that big (I try to keep scraps to <200m). If anyone cares to investigate this then the benarat dataset illustrates the problem. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
On Thu, 18 Aug 2005 11:26:26 +0100, Wookey wrote
Hmm, so as it goes wrong with the default (scale 1:200) that suggets I have one scrap which is >560m long. I don't think I do have anything that big (I try to keep scraps to <200m).
If anyone cares to investigate this then the benarat dataset illustrates the problem.
It's the scrap faketerikan_s15, which contains two survey stations (used for calibration?) really far from the passage. --- How to find where the problem is: * therion log window displays metapost's progress, it displays [33] just before the error; that means that picture number 33 has been sucessfuly processed and the error is in the next one * run therion in the -d (debug) mode * go to thTMPDIR * open the file data.mp and find picture 34 (it starts "beginfig(34);" ;-) * find the "current_scrap" assignment preceding the picture * it's "faketerikan_s15@terikan.dummy" It's really not straightforward but it's hard to make a better link between metapost and therion when an error occurs. In this particular case it's enough for therion to check the size of scraps and give a reasonable error message -- hopefully Stacho will do it. Martin
Martin Budaj wrote:
On Thu, 18 Aug 2005 11:26:26 +0100, Wookey wrote
Hmm, so as it goes wrong with the default (scale 1:200) that suggets I have one scrap which is >560m long. I don't think I do have anything that big (I try to keep scraps to <200m).
If anyone cares to investigate this then the benarat dataset illustrates the problem.
It's the scrap faketerikan_s15, which contains two survey stations (used for calibration?) really far from the passage.
Ah yes. All those faketerikan scraps use the same two (fake) stations - which are just two random well-spaced stations in the fake survey we generated from the original drawing. This scheme worked a lot better than using fake stations with each scrap (as used on the fakebluemoon survey) - that led to a lot of distortions in scraps where there should have been none.
---
How to find where the problem is: * therion log window displays metapost's progress, it displays [33] just before the error; that means that picture number 33 has been sucessfuly processed and the error is in the next one * run therion in the -d (debug) mode * go to thTMPDIR * open the file data.mp and find picture 34 (it starts "beginfig(34);" ;-) * find the "current_scrap" assignment preceding the picture * it's "faketerikan_s15@terikan.dummy"
Thanx - that's useful to know. I've been wondering what all those numbers meant :-) As you say, a message like 'scrap <foo> is too large to be processed' would be better. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
participants (5)
-
Martin Budaj -
Martin Sluka -
Olly Betts -
Stacho Mudrak -
Wookey