Size of pdf error when final pdf size should be OK
I'm having a problem with creating pdf plan maps of a smallish area (about 1 km x 1.5km) with a source surface image covering about 5km x 7 km. For a cave in one particular corner (near bottom left) of the larger image it works fine at a scale 1:1000. (It was giving problems with the map produced being much bigger than the cave extent, but Stacho (or was it Martin?) fixed this bug for me.) For another cave elsewhere on the image (sort of top centre) I get the error reported in the scale 1 1000 log file attached, and no output. For this other cave it compiles fine if the surface image is off, or if the surface image is on and the scale is 1:2000 as in the attached scale 1 2000 log file. (Use a text comparator to spot the differences in the two attachments). If I debug the problem run and check the intermediate data.pdf file produced, the cave is plotted on the wrong part of the surface image, but is otherwise perfect. Perhaps the error is due to the size of the pdf page produced as part of an intermediate step, as the final pdf page is well within the 5m size limit. In all cases I am using 'rotate 70' so that may be adding a small complication. Any ideas what is going on? Is my guess as to the case likely to be correct? Might it be possible to get a 1:1000 output (1.5m long) without chopping my overall source image into smaller pieces? After all, it works in one case and not another. Regards Bruce
On Thu, Jul 15, 2010 at 1:40 PM, Bruce <dangle@tomo.co.nz> wrote:
For another cave elsewhere on the image (sort of top centre) I get the error reported in the scale 1 1000 log file attached, and no output. For this other cave it compiles fine if the surface image is off, or if the surface image is on and the scale is 1:2000 as in the attached scale 1 2000 log file. (Use a text comparator to spot the differences in the two attachments).
If I debug the problem run and check the intermediate data.pdf file produced, the cave is plotted on the wrong part of the surface image, but is otherwise perfect.
Perhaps the error is due to the size of the pdf page produced as part of an intermediate step, as the final pdf page is well within the 5m size limit.
Exactly. The critical dimension is a difference between lower-left corner of the cave and lower-left corner of the image. If it is too large for TeX, it uses maximal acceptable value as displayed in the log file and you get wrong placement of the cave relative to background.
Might it be possible to get a 1:1000 output (1.5m long) without chopping my overall source image into smaller pieces? After all, it works in one case and not another.
Displaying both caves could avoid the problem. It is theoretically possible to fix it e.g. by scaling down the coordinates passed to TeX by factor of 10 and then rescale the map only in PDF file by setting transformation matrices; but this would be quite lot of work. Splitting the image seems to be the best idea currently. Martin
Thanks for that excellent clarification Martin. Good to know it is not necessarily a bug, and perhaps disturbing that I am becoming "Therion intuitive". Of course I look forward to your theoretical solution in due course, but in the meantime I will try to adapt to the workarounds. Bruce -----Original Message----- From: therion-bounces@speleo.sk [mailto:therion-bounces@speleo.sk] On Behalf Of Martin Budaj Sent: Friday, 16 July 2010 2:39 a.m. To: List for Therion users Subject: Re: [Therion] Size of pdf error when final pdf size should be OK On Thu, Jul 15, 2010 at 1:40 PM, Bruce <dangle@tomo.co.nz> wrote:
For another cave elsewhere on the image (sort of top centre) I get the error reported in the scale 1 1000 log file attached, and no output. For this other cave it compiles fine if the surface image is off, or if the surface image is on and the scale is 1:2000 as in the attached scale 1 2000 log file. (Use a text comparator to spot the differences in the two attachments).
If I debug the problem run and check the intermediate data.pdf file produced, the cave is plotted on the wrong part of the surface image, but is otherwise perfect.
Perhaps the error is due to the size of the pdf page produced as part of an intermediate step, as the final pdf page is well within the 5m size limit.
Exactly. The critical dimension is a difference between lower-left corner of the cave and lower-left corner of the image. If it is too large for TeX, it uses maximal acceptable value as displayed in the log file and you get wrong placement of the cave relative to background.
Might it be possible to get a 1:1000 output (1.5m long) without chopping my overall source image into smaller pieces? After all, it works in one case and not another.
Displaying both caves could avoid the problem. It is theoretically possible to fix it e.g. by scaling down the coordinates passed to TeX by factor of 10 and then rescale the map only in PDF file by setting transformation matrices; but this would be quite lot of work. Splitting the image seems to be the best idea currently. Martin _______________________________________________ Therion mailing list Therion@speleo.sk http://mailman.speleo.sk/mailman/listinfo/therion
On Thu, Jul 15, 2010 at 11:13 PM, Bruce <dangle@tomo.co.nz> wrote:
Of course I look forward to your theoretical solution in due course
Hi Bruce, could you try whether inserting following lines in the layout used for creating the map fixes the problem? Martin code tex-map \def\bitmapcorr#1#2#3#4#5#6#7{% \xcorr=0bp\advance\xcorr by\extraW\advance\xcorr by\overlap \ycorr=0bp\advance\ycorr by\extraS\advance\ycorr by\overlap \dimtobp{\xcorr}\edef\wdth{\tmpdef}% \dimtobp{\ycorr}\edef\hght{\tmpdef}% \pdfliteral{q 1 0 0 1 \wdth\space\hght\space cm #1 #2 #3 #4 #5 #6 cm}% two-step transformation to avoid overflow \rlap{\pdfrefximage#7}% \pdfliteral{Q}% }
You're a marvel! It works perfectly, at the scales where previously there was a problem, where it previously was not, and with the surface image off. It might even be a fairly robust solution! Bruce -----Original Message----- From: therion-bounces@speleo.sk [mailto:therion-bounces@speleo.sk] On Behalf Of Martin Budaj Sent: Wednesday, 21 July 2010 4:07 a.m. To: List for Therion users Subject: Re: [Therion] Size of pdf error when final pdf size should be OK On Thu, Jul 15, 2010 at 11:13 PM, Bruce <dangle@tomo.co.nz> wrote:
Of course I look forward to your theoretical solution in due course
Hi Bruce, could you try whether inserting following lines in the layout used for creating the map fixes the problem? Martin
Hi We are trying to send our Charterhouse survey to Descent for publication. Chris Howes, the editor, would love to have an output he can use directly, but as yet this is not to be. Over a series of emails here are some of the points that he has made. I hope I have not taken them out of context in editing them down to a single email. (I also accept some of the comments may come from the fact I do not understand some of the features of Therion or some of the terminology) Hope this is useful for future development 1 My problem was that if I'm using colour on a page, I often use a tinted background and/or run bits of survey across a photo corner or something (or even over a graphic) as part of my layout. But if there is transparency in the fill, I can't do that. What's needed is for no transparency to be used in 'normal' fills = all passages, but instead a solid colour. For overlying bits, transparency is fine for the upper section, but not the lower. Transparency for all 'non cave' bits = the background *should* be transparent of course. 2 Another oddity - there seemed to be a lot of non-stroked detail/bits way off the passages/survey that don't show up but are selectable. Doesn't seem to affect anything and I can't even see them, but only spot that *something* is there when trying to select the image. Odd - not a problem (as far as I know) but as this is a report on what happens here, I thought I'd mention it. 3a (svg with walls and lables only, no passage fill colour) I can change the line weight okay, but as I hit as a problem before when working on files like this, the paths don't seem to stay as a path (text, for example, aren't words but just single letters) and I can't figure out how to do a fill to add colour to the passage content. That is, if there is a colour there, I'm pretty sure I can change it but I can't select enough to actually add a fill in the first place. 3b (svg with only cross section switched off) The detailed view won't open correctly in Illustrator - there are warnings about too many nested groups (surprising considering the complexity of the .svg files for the Three Counties that are in the next issue, which breezed through) and that it might not look correct, then it opens with most of the content missing (the only bit that appears fully intact is at the extreme bottom and only for a few metres). Needed for this I think/suspect: some work in flattening/decreasing grouping in the original before creating the .svg, but I don't have experience of the creating package (nor any other vector software). 3c (pdf with cross sections off) Having imported the pdf to Illustrator, as I mentioned already evident is that the file has been simplified by having taken that route, rather than the svg. At least, that's my assumption as it opened without warning about groups, as opposed to opening without any real content remaining.
Andy, try to rasterize PDF in Photoshop to 360 or 240 or 180 dpi (depending on scale you need to reduce size). It will reduce all problems with too huge vector formats. Martin On 21.7.2010, at 9:58, Andrew Atkinson wrote:
Hi
We are trying to send our Charterhouse survey to Descent for publication. Chris Howes, the editor, would love to have an output he can use directly, but as yet this is not to be.
Over a series of emails here are some of the points that he has made. I hope I have not taken them out of context in editing them down to a single email. (I also accept some of the comments may come from the fact I do not understand some of the features of Therion or some of the terminology) Hope this is useful for future development
1 My problem was that if I'm using colour on a page, I often use a tinted background and/or run bits of survey across a photo corner or something (or even over a graphic) as part of my layout. But if there is transparency in the fill, I can't do that. What's needed is for no transparency to be used in 'normal' fills = all passages, but instead a solid colour. For overlying bits, transparency is fine for the upper section, but not the lower.
Transparency for all 'non cave' bits = the background *should* be transparent of course.
2 Another oddity - there seemed to be a lot of non-stroked detail/bits way off the passages/survey that don't show up but are selectable. Doesn't seem to affect anything and I can't even see them, but only spot that *something* is there when trying to select the image. Odd - not a problem (as far as I know) but as this is a report on what happens here, I thought I'd mention it.
3a (svg with walls and lables only, no passage fill colour)
I can change the line weight okay, but as I hit as a problem before when working on files like this, the paths don't seem to stay as a path (text, for example, aren't words but just single letters) and I can't figure out how to do a fill to add colour to the passage content. That is, if there is a colour there, I'm pretty sure I can change it but I can't select enough to actually add a fill in the first place.
3b (svg with only cross section switched off) The detailed view won't open correctly in Illustrator - there are warnings about too many nested groups (surprising considering the complexity of the .svg files for the Three Counties that are in the next issue, which breezed through) and that it might not look correct, then it opens with most of the content missing (the only bit that appears fully intact is at the extreme bottom and only for a few metres). Needed for this I think/suspect: some work in flattening/decreasing grouping in the original before creating the .svg, but I don't have experience of the creating package (nor any other vector software).
3c (pdf with cross sections off) Having imported the pdf to Illustrator, as I mentioned already evident is that the file has been simplified by having taken that route, rather than the svg. At least, that's my assumption as it opened without warning about groups, as opposed to opening without any real content remaining.
_______________________________________________ Therion mailing list Therion@speleo.sk http://mailman.speleo.sk/mailman/listinfo/therion
Chris cannot reply directly to the list so I will have to be intermediary I can turn a pdf (or any vector file) into a 'usable' file by rasterising it. I often do. I can set the ppi when doing so at whatever I wish, so that is not a difficulty. But, for this purpose: 1. The file itself is too massive to be used - we are talking hundreds of mb here (after sizing for the page) 2. It is no longer editable, thus removing the whole point of the exercise. It will rastorise with the same parameters as the native file - I won't be able to edit the line thickness, in particular, not any other element (which is the whole point of wanting the .ai file to work). Rastored files are actually my first stage when I redraw surveys, so I can use them to create my own file - it's what I base that work on, so I'm well used to their benefits and limitations. For this, it doesn't work. I think that point 1 in your mail to the therion group might mislead some - this factor of transparency must be one that is under the control of the person creating the file (the choice of using transparency or a solid colour) and not a restriction of the package. I suspect it is something that is easy to do to create an effect and, reasonably, it is therefore done ... But doesn't help if the aim is print on paper by a third party (me!). Chris On 21/07/10 09:04, Martin Sluka wrote:
Andy, try to rasterize PDF in Photoshop to 360 or 240 or 180 dpi (depending on scale you need to reduce size). It will reduce all problems with too huge vector formats.
Martin
On 21.7.2010, at 9:58, Andrew Atkinson wrote:
Hi
We are trying to send our Charterhouse survey to Descent for publication. Chris Howes, the editor, would love to have an output he can use directly, but as yet this is not to be.
Over a series of emails here are some of the points that he has made. I hope I have not taken them out of context in editing them down to a single email. (I also accept some of the comments may come from the fact I do not understand some of the features of Therion or some of the terminology) Hope this is useful for future development
1 My problem was that if I'm using colour on a page, I often use a tinted background and/or run bits of survey across a photo corner or something (or even over a graphic) as part of my layout. But if there is transparency in the fill, I can't do that. What's needed is for no transparency to be used in 'normal' fills = all passages, but instead a solid colour. For overlying bits, transparency is fine for the upper section, but not the lower.
Transparency for all 'non cave' bits = the background *should* be transparent of course.
2 Another oddity - there seemed to be a lot of non-stroked detail/bits way off the passages/survey that don't show up but are selectable. Doesn't seem to affect anything and I can't even see them, but only spot that *something* is there when trying to select the image. Odd - not a problem (as far as I know) but as this is a report on what happens here, I thought I'd mention it.
3a (svg with walls and lables only, no passage fill colour)
I can change the line weight okay, but as I hit as a problem before when working on files like this, the paths don't seem to stay as a path (text, for example, aren't words but just single letters) and I can't figure out how to do a fill to add colour to the passage content. That is, if there is a colour there, I'm pretty sure I can change it but I can't select enough to actually add a fill in the first place.
3b (svg with only cross section switched off) The detailed view won't open correctly in Illustrator - there are warnings about too many nested groups (surprising considering the complexity of the .svg files for the Three Counties that are in the next issue, which breezed through) and that it might not look correct, then it opens with most of the content missing (the only bit that appears fully intact is at the extreme bottom and only for a few metres). Needed for this I think/suspect: some work in flattening/decreasing grouping in the original before creating the .svg, but I don't have experience of the creating package (nor any other vector software).
3c (pdf with cross sections off) Having imported the pdf to Illustrator, as I mentioned already evident is that the file has been simplified by having taken that route, rather than the svg. At least, that's my assumption as it opened without warning about groups, as opposed to opening without any real content remaining.
_______________________________________________ Therion mailing list Therion@speleo.sk http://mailman.speleo.sk/mailman/listinfo/therion
_______________________________________________ Therion mailing list Therion@speleo.sk http://mailman.speleo.sk/mailman/listinfo/therion
On Wed, Jul 21, 2010 at 10:39 AM, Andrew Atkinson <andrew@wotcc.org.uk> wrote:
2. It is no longer editable, thus removing the whole point of the exercise. It will rastorise with the same parameters as the native file - I won't be able to edit the line thickness, in particular, not any other element (which
You can also consider changing line width in therion (metapost) directly. The easiest way is to play with base-scala and scale combinations in layout. Martin
I have just started on the metapost journey, expect some more mails I have been using the base-scale trick, thanks Andrew On 21/07/10 13:15, Martin Budaj wrote:
On Wed, Jul 21, 2010 at 10:39 AM, Andrew Atkinson<andrew@wotcc.org.uk> wrote:
2. It is no longer editable, thus removing the whole point of the exercise. It will rastorise with the same parameters as the native file - I won't be able to edit the line thickness, in particular, not any other element (which
You can also consider changing line width in therion (metapost) directly. The easiest way is to play with base-scala and scale combinations in layout.
Martin _______________________________________________ Therion mailing list Therion@speleo.sk http://mailman.speleo.sk/mailman/listinfo/therion
On page 68 of the Therion book Customizing text labels There is a preliminary interface to changing font sizes for labels via the METAPOST macro fonts_setup(<tinysize>,<smallsize>,<normalsize>,<largesize>,<hugesize>); which may be used inside of the code metapost section of the layout command. <normalsize> applies to point label, <smallsize> applies to remark and all other point labels. Each of them may apply to line label according to its -size option. Example: code metapost fonts_setup(6,8,10,14,20); % default values depend on scale; for 1:200 they are 7,8,10,12,14 Now this works well when I have used -scale m etc on the line label. But as I changes text sizes it sometimes overlaps the passage, as it seems to use the line as a centre. so I wanted to try something cleverer, similar to the -align available with point label, align only works with points and on page 26 it gives me this size <number> ◃ line width (left and right sizes are set to one half of this value) r-size <number> ◃ size of the line to the right l-size <number> ◃ same to the left. Required for slope type. Which suggests to me, with page68, that I should be able to use -r-size normalsize which would put the text on the right side only but got the error no line point specified (tried adding -l-size 0 just in case this was needed, but same error) Also checked by adding a number as well eg -r-size 20 but same error. Am I trying to misuse this option? If not what am I missing? If I have not interpreted this right, is there a way to make the text only be on the left or right of the line thanks Andrew
... text ... seems ... to use the line as a centre. so I wanted to try something cleverer, similar to the -align available with point label, align only works with points and on page 26 it gives me this size <number> ◃ line width (left and right sizes are set to one half of this value) r-size <number> ◃ size of the line to the right l-size <number> ◃ same to the left. Required for slope type. ...
I too have wanted to get 'line label's to -align top or -align bottom (wrt local line co-ords?), rather than the default -align centre. As far as I know -size <> etc scales the non-text features of the line and does not relate to text size in any way (but really I'm only guessing - I've almost never used it). My work-around has been to use 'point labels' as much as possible. These are of course, straight, and still have insertion point alignment issues if scrap sketches are not oriented consistent with respect to the 'rotate' used in the layout. Bruce
On Wed, Jul 21, 2010 at 9:58 AM, Andrew Atkinson <andrew@wotcc.org.uk> wrote:
1 My problem was that if I'm using colour on a page, I often use a tinted background and/or run bits of survey across a photo corner or something (or even over a graphic) as part of my layout. But if there is transparency in the fill, I can't do that. What's needed is for no transparency to be used in 'normal' fills = all passages, but instead a solid colour. For overlying bits, transparency is fine for the upper section, but not the lower.
Transparency for all 'non cave' bits = the background *should* be transparent of course.
think that point 1 in your mail to the therion group might mislead some - this factor of transparency must be one that is under the control of the person creating the file (the choice of using transparency or a solid colour) and not a restriction of the package. I suspect it is something that is easy to do to create an effect and, reasonably, it is therefore done ...
It is possible to turn transparency feature completely off using 'transparency off' in layout. If the transparency is on, there is a nontrasparent white fill below all passages to eliminate combining effects with coloured background (if I remember correctly, the white fill is omitted if 'color map-bg' is white in current therion).
2 Another oddity - there seemed to be a lot of non-stroked detail/bits way off the passages/survey that don't show up but are selectable. Doesn't seem to affect anything and I can't even see them, but only spot that *something* is there when trying to select the image. Odd - not a problem (as far as I know) but as this is a report on what happens here, I thought I'd mention it.
This is a feature, lot of objects are clipped by passage walls. They are not displayed, although present in the file.
3a (svg with walls and lables only, no passage fill colour)
I can change the line weight okay, but as I hit as a problem before when working on files like this, the paths don't seem to stay as a path (text, for example, aren't words but just
Text along a path should be the only exception -- it is broken to letters in MetaPost so that Therion has more control about placement of letters.
single letters) and I can't figure out how to do a fill to add colour to the passage content. That is, if there is a colour there, I'm pretty sure I can change it but I can't select enough to actually add a fill in the first place.
It can be really tricky to find a proper object.
3b (svg with only cross section switched off) The detailed view won't open correctly in Illustrator - there are warnings about too many nested groups (surprising considering the complexity of the .svg files for the Three Counties that are in the next issue, which breezed through) and that it might not look correct, then it opens with most of the content missing (the only bit that appears fully intact is at the extreme bottom and only for a few metres). Needed for this I think/suspect: some work in flattening/decreasing grouping in the original before creating the .svg, but I don't have experience of the creating package (nor any other vector software).
You could decrease the number of groups by turning 'layers' and 'transparency' off in layout. Maps are really complex and you cannot avoid groups completely. Hope this helps, Martin
participants (4)
-
Andrew Atkinson -
Bruce -
Martin Budaj -
Martin Sluka