tag:old.nabble.com,2006:forum-1628Nabble - Ghostscript2009-11-30T00:36:32ZGhostscript consists of an interpreter for the PostScript language and the PDF file format, a set of C procedures (the Ghostscript library) that implement the graphics capabilities that appear as primitive operations in the PostScript language, and a wide variety of output drivers for various file formats and printers. Ghostscript home is <a href="http://ghostscript.com/" target="_top" rel="nofollow">here</a>.tag:old.nabble.com,2006:post-26570768Re: Need opinions for fixing bug #6908342009-11-30T00:36:32Z2009-11-30T00:36:32ZKen SharpAt 18:46 27/11/2009 +0900, you wrote:
<br><br><div class='shrinkable-quote'><br>>This patch works as it fixes bug #690384, but there are issues to be
<br>>discussed.
<br>>
<br>>1) gs_font_cid0.cidata.glyph_data() is called at least twice for each
<br>>CID. This is inefficient.
<br>>2) CID 0 fallback logic is distributed into three functions, one in
<br>>psi and two in base.
<br>>3) Current CID 0 fallback logic does not handle errors correctly.
<br>>Some errors should be risen immediately before falling back to CID 0.
<br>>(I didn't do this because I didn't want to distribute complex code
<br>>three places apart in a system.)
<br>>4) Applying this patch makes bug #687832 go back in life.
<br>>
<br>>To tell the truth, I don't know where to start. Maybe current font
<br>>handing in gs doesn't go along well with CIDFont.
</div><br>Well CIDFont handling was an addition to Ghostscript, since GS predates
<br>CIDFonts, so its not entirely surprising that its a slightly klunky fit. I
<br>would leave the inefficiencies in 1 and 2 for now, but feel free to raise a
<br>new enhancement bug report for them if you want to make sure they don't get
<br>forgotten.
<br><br>IMO Point 3 should be a new 'nice to fix' (ie P4) bug, unless a customer
<br>raises it as an error report. I'd be wary of converting a .notdef print
<br>into an error, its entirely possible that Acrobat/CPSI behaves this way and
<br>we've simply copied it.
<br><br><br>> On the other hand,
<br>>I think I may commit this patch because there is a customer waiting.
<br>>I would like to hear comments from you. I would appreciate any hints,
<br>>directions or priorities you could give me.
<br><br>As regards #687832, it 'looks' like we need to set the CTM correctly which
<br>I think ought to be possible though presumably we need different logic than
<br>was previously applied.
<br><br>This issue appears to affect a broad range of InDesign files (ID produces
<br>many CIDFonts in its PostScript and particularly PDF output now). Unless
<br>absolutely essential I'd prefer to wait on a fix for #690834 until you can
<br>fix both problems. I suspect the ID issue is considerably more common than
<br>this new issue and re-introducing a widespread problem in order to fix an
<br>uncommon problem doesn't seem like a good idea.
<br><br>By the way, I noticed from your patch for gschar0.c:
<br><br>@@ -73,10 +74,11 @@
<br> if (fdepth == MAX_FONT_STACK)\
<br> return_error(gs_error_invalidfont);\
<br> pfont = pdata->FDepVector[pdata->Encoding[fidx]];\
<br>- if (++fdepth > orig_depth || pfont != pte->fstack.items[fdepth].font ||\
<br>- orig_index != fidx)\
<br>+ pte->fstack.items[fdepth].index = fidx;\
<br>+ if (++fdepth > orig_depth || pfont != pte->fstack.items[fdepth].font)\
<br> pte->fstack.items[fdepth].font = pfont, changed = 1;\
<br>- pte->fstack.items[fdepth].index = fidx
<br>+ else\
<br>+ ;
<br><br>I don't recall seeing a specific prohibition in the coding standard, but
<br>I've not seen anywhere else in GS use the multiple statements on single
<br>line approach in a conditional, and I think it would be better to elide the
<br>empty else clause altogether, ie:
<br><br> if (++fdepth > orig_depth || pfont != pte->fstack.items[fdepth].font) {
<br> pte->fstack.items[fdepth].font = pfont;
<br> changed = 1;
<br> }
<br><br><br><br>My 2p worth,
<br><br><br> Ken
<br><br>_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26570768&i=0" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26540030Need opinions for fixing bug #6908342009-11-27T01:46:52Z2009-11-27T01:46:52ZMasaki UshizakaDear gs-devel,
<br><br>This is a patch I wrote to fix bug #690834. I wanted to hear opinions
<br>from experienced developers.
<br><br>This patch implements fix 1-4 I mentioned in bug #690834 comment #8,
<br>but leaves fix 5 (find another solution for bug #687832).
<br>This one also includes a patch I proposed in thread '[gs-devel]
<br>Proposal for changing semantics of gx_font_stack_item_t::index (bug
<br>#690834)'.
<br><br>A localcluster test said there are differences in tests_private/
<br>comparefiles/Bug687832.pdf, which I expected because it reverses a
<br>change in rev. 5613 which is a fix for bug #687832. It also showed
<br>differences in tests_private/comparefiles/Bug689748.pdf. I see one of
<br>the letter during a string rendered one dot horizontally shifted, I
<br>believe this is a number rounding issue and not a real problem.
<br><br>Now gs_type0_next_char_glyph() calls gs_font_cid0.cidata.glyph_data()
<br>for each CIDs in string. show_state_setup() also calls it under
<br>'glyphshow' or 'cshow'. But this wasn't the end.
<br><br>CID 0 glyph in a CIDFont serves a role of .notdef character.
<br>The .notdef fallback process typically takes two stages. First during
<br>the consulting of the CMap dictionary, second during the access of
<br>glyphs in the CIDFont. If the requested CID is not in the CIDFont, it
<br>falls back to CID 0. Without completing this second process, we do
<br>not know what FDArray is going to be used. But current code does this
<br>second process long after gs_type0_next_char_glyph() or
<br>show_state_setup() is called, in ztype9mapcid() (psi/zfcid0.c). To
<br>make this, I copied the logic from ztype9mapcid() into
<br>gs_type0_next_char_glyph() and show_state_setup().
<br><br>This patch works as it fixes bug #690384, but there are issues to be
<br>discussed.
<br><br>1) gs_font_cid0.cidata.glyph_data() is called at least twice for each
<br>CID. This is inefficient.
<br>2) CID 0 fallback logic is distributed into three functions, one in
<br>psi and two in base.
<br>3) Current CID 0 fallback logic does not handle errors correctly.
<br>Some errors should be risen immediately before falling back to CID 0.
<br>(I didn't do this because I didn't want to distribute complex code
<br>three places apart in a system.)
<br>4) Applying this patch makes bug #687832 go back in life.
<br><br>To tell the truth, I don't know where to start. Maybe current font
<br>handing in gs doesn't go along well with CIDFont. On the other hand,
<br>I think I may commit this patch because there is a customer waiting.
<br>I would like to hear comments from you. I would appreciate any hints,
<br>directions or priorities you could give me.
<br><br>Best Regards,
<br>Masaki Ushizaka
<br><br><br><br /> <br /><br><br><br />_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26540030&i=0" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>b690834_p2.patch</strong> (8K) <a href="http://old.nabble.com/attachment/26540030/0/b690834_p2.patch" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26503136Re: Converting TIF from PDF created by Word with UseCropBox option2009-11-24T12:57:59Z2009-11-24T12:57:59ZLevi WilsonAlex,
<br><br>Thanks for the quick response. How would I use the patch that is
<br>shown in pdf_main.ps? I am on Windows and the installation for
<br>windows does not package a gs/Resource/Init/pdf_main.ps with it. How
<br>should I proceed from here?
<br><br>Thanks,
<br><br>Levi
<br><br>On Tue, Nov 24, 2009 at 1:09 PM, Alex Cherepanov <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26503136&i=0" target="_top" rel="nofollow">alexcher@...</a>> wrote:
<div class='shrinkable-quote'><br>> Levi wrote:
<br>>>
<br>>> I've recently switched from GhostScript 8.63 to GhostScript 8.70.
<br>>
<br>> ...
<br>>>
<br>>> I noticed the warning about the page not having a /MediaBox attribute.
<br>>
<br>> Yes, this is a bug and regression in v. 8.70.
<br>> See <a href="http://bugs.ghostscript.com/show_bug.cgi?id=690676" target="_top" rel="nofollow">http://bugs.ghostscript.com/show_bug.cgi?id=690676</a><br>> for discussion and a patch.
<br>>
<br>> Regards,
<br>> Alex Cherepanov
<br>>
<br>>
</div>_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26503136&i=1" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26500799Re: Converting TIF from PDF created by Word with UseCropBox option2009-11-24T10:09:48Z2009-11-24T10:09:48ZAlex CherepanovLevi wrote:
<br>> I've recently switched from GhostScript 8.63 to GhostScript 8.70.
<br>...
<br>> I noticed the warning about the page not having a /MediaBox attribute.
<br>Yes, this is a bug and regression in v. 8.70.
<br>See <a href="http://bugs.ghostscript.com/show_bug.cgi?id=690676" target="_top" rel="nofollow">http://bugs.ghostscript.com/show_bug.cgi?id=690676</a><br>for discussion and a patch.
<br><br>Regards,
<br>Alex Cherepanov
<br><br>_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26500799&i=0" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26500679Converting TIF from PDF created by Word with UseCropBox option2009-11-24T10:04:32Z2009-11-24T10:04:32ZLevi WilsonI've recently switched from GhostScript 8.63 to GhostScript 8.70.
<br>After doing so, my program that converted PDF files that were made
<br>with Microsoft Word now fails. Here is the output from the
<br>command-line of one that fails:
<br><br>C: >>gswin32c.exe -dPrinted -dBATCH -dUseCropBox -dNOPAUSE -q
<br>-dDITHERPPI=100 -sDEVICE=tiffg4 -r600x600
<br>-sOutputFile="c:\temp\coverletter.tif" c:\temp\coverletter.pdf
<br> **** Page has no /MediaBox attribute. Using the current page size.
<br>Error: /stackunderflow in --index--
<br>Operand stack:
<br> --dict:8/8(L)-- 612.0 792.0 3
<br>Execution stack:
<br> %interp_exit .runexec2 --nostringval-- --nostringval--
<br>--nostringval-- 2 %stopped_push --nostringval--
<br>--nostringval-- --nostring
<br>val-- false 1 %stopped_push 1862 1 3 %oparray_pop 1861
<br> 1 3 %oparray_pop 1845 1 3 %oparray_pop --nostringval--
<br> --nost
<br>ringval-- 2 1 1 --nostringval-- %for_pos_int_continue
<br>--nostringval-- --nostringval--
<br>Dictionary stack:
<br> --dict:1159/1684(ro)(G)-- --dict:1/20(G)-- --dict:75/200(L)--
<br>--dict:75/200(L)-- --dict:106/127(ro)(G)-- --dict:285/300(ro)(G)--
<br> --dict
<br>:20/25(L)-- --dict:2/6(L)--
<br>Current allocation mode is local
<br>GPL Ghostscript 8.70: Unrecoverable error, exit code 1
<br><br>I noticed the warning about the page not having a /MediaBox attribute.
<br> Therefore I removed the -dUseCropBox option and the conversion
<br>worked. I have a couple of questions, why does the -dUseCropBox
<br>parameter cause gs to fail like this? And two, by removing that
<br>option from the command-line what am I really doing? Will it hurt
<br>anything? I use this command to not only convert PDF images created
<br>by Word to TIF, but also PDF images of surveys that are sent to us via
<br>our translation vendor. The surveys that are sent to us convert to
<br>TIF from PDF just fine with the -dUseCropBox parameter.
<br><br>Thanks in advance,
<br><br>Levi
<br>_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26500679&i=0" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26498462Using .joboptions file on linux/ubuntu : pdfwrite2009-11-24T07:59:29Z2009-11-24T07:59:29ZmaweI have a Adobe .joboptions file (<a href="http://epsilon.slu.se/Repros5.joboptions" target="_top" rel="nofollow">http://epsilon.slu.se/Repros5.joboptions</a>) which I would like to use when creating pdf:s in OpenOffice on linux/ubuntu. As I understand, .joboptions files are just post script, and could (somehow) be used with the ghostscript pdfwrite device. Could anyone point me in the right direction for how to accomplish this?
<br><br>Thanks in advance,
<br>Martin<p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26421412Bug converting EPS (CMYK) -> PDF (become RGB)2009-11-19T09:41:37Z2009-11-19T09:41:37Zy.rousselHello,
<br><br>I use the following command to convert CMYK EPS to PDF, but this one is RGB.
<br>I just want a CMYK PDF. How to do ?
<br><br>gswin32c -q -dNoPause -dSAFER -dNOPAUSE -dBATCH -dDEVICEWIDTHPOINTS=100 -dDEVICEHEIGHTPOINTS=190 -sDEVICE=pdfwrite -sOutputFile="test_.pdf" -f "test.eps"<a href="http://old.nabble.com/file/p26421412/test.eps" target="_top">test.eps</a><br><br>Thanks and regards
<br><br>Y.Roussel<p>From forum: <a href="http://old.nabble.com/Ghostscript---bugs-f1630.html" embed="fixTarget[1630]" target="_top" >Ghostscript - bugs</a></p>tag:old.nabble.com,2006:post-26422698Re: Proposal for changing semantics of gx_font_stack_item_t::index (bug #690834)2009-11-19T00:37:11Z2009-11-19T00:37:11ZKen Sharp<br><br>>Each member of fstack.items[0.. fstack.depth-1].font is a composite
<br>>font and its descendant fonts can be accessed by described above. But
<br>>contents of FDepVector are references to another gs_font objects.
<br>>'fstack' is an array describing a single path of fonts those ware
<br>>selected to 'show' current glyph. gs_type0_next_char_glyph() is
<br>>called for each glyph to know if selected descendant font path has
<br>>been changed for next glyph.
<br><br>Ah, that makes more sense now, thanks for the explanation.
<br><br> Ken
<br><br>_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26422698&i=0" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26422413Re: Proposal for changing semantics of gx_font_stack_item_t::index (bug #690834)2009-11-19T00:24:29Z2009-11-19T00:24:29ZMasaki Ushizaka<br>On 2009/11/19, at 0:49, Ken Sharp wrote:
<br><div class='shrinkable-quote'><br>> At 22:42 18/11/2009 +0900, Masaki Ushizaka wrote:
<br>>
<br>>
<br>>> fstack.items[0] is a rootfont. fstack.items[1 .. fstack.depth-1] are
<br>>> intermediate composite fonts. And fstack.items[fstack.depth] is a
<br>>> base font or a CIDFont. These are aligned in
<br>>> gschar0.c:gs_type0_next_char_glyph().
<br>>
<br>> I have no objection to the patch, what I see looks sensible, and is
<br>> the way I thought it worked anyway....
<br>>
<br>> I do have some questions about the existing scheme for my own
<br>> education though if you don't mind answering them.
<br>>
<br>> fstack.items[0].font is a root font (type 0 composite font)
<br>> currently fstack.items[0].index is always 0.
<br>>
<br>> You describe fstack.items[1 .. fstack.depth-1] (presumably
<br>> the .font member ?) as 'intermediate composite fonts' are these type
<br>> 0 composite fonts, or base fonts of some kind, or can it be either ?
</div><br>Yes, I meant '.font' member. 'Intermediate composite fonts' are just
<br>usual FontType 0 composite fonts. I said 'intermediate' because some
<br>of us may not aware that composite fonts can be nested up to five
<br>levels.
<br><br><br>> fstack.items[fstack.depth], again presumably the font member, is a
<br>> base font or CIDFont. I can see what this means for CIDFonts, what
<br>> is meant by a 'base font', a type 0 or something else ?
<br><br>The 'base font' is a red book terminology. PLRM3 p. 321, "Fonts of
<br>type 1, 2, 3, 14, and 42 are called base fonts." This description may
<br>not be sufficient. In Level 2, 'base fonts' are the all fonts but
<br>composite fonts. PLRM2 p. 265, "Type 0 is a composite font composed
<br>of other fonts called base fonts, organized hierarchically." That is,
<br>the fonts have actual glyph descriptions. It actually includes
<br>Adobe's secret font types like 4, 5, 7... I have been believing that
<br>the CIDFonts are also base fonts but PLRM3 distinguish it from base
<br>font. In PS3, there are three font classes: composite font, base font
<br>and CID keyed font. The CID keyed font is not a base font probably
<br>because Adobe's original plan was to replace all base fonts with
<br>CIDFonts.
<br><br><div class='shrinkable-quote'><br>>> Currently, 'index' member is used:
<br>>> For n=0: fstack.items[0].index == 0 (not used)
<br>>> For n=[1 .. fstack.depth]:
<br>>> fstack.items[n].index == font number used in
<br>>> fstack.items[n-1].font
<br>>> (fstack.items[n-1].font.data.FDepVector[indexed by
<br>>> fstack.items[n].index] == fstack.items[n].font)
<br>>
<br>> So this implies that each member of fstack.items[1...fstack.depth-1]
<br>> is potentially a composite font with its own array of descendants ?
</div><br>Each member of fstack.items[1.. fstack.depth-1].font is always a
<br>composite font, as well as fstack.items[0].font. Its descendant fonts
<br>can be accessed by casting it to 'gs_font_type0' and
<br>accessing .data.FDepVector[]. This real code would be:
<br><br>gs_font_type0 *pfont0 = (gs_font_type0 *)fstack.item[n].font;
<br>assert(pfont->data.FDepVector[pfont->data.Encoding[fstack.item[n
<br>+1].index]] == fstack.item[n+1].font);
<br><br><br>> It also seems to imply that when a composite font has composite
<br>> descendants, the descendants have FDepVector arrays whose members
<br>> are elements of the fstack array ?
<br><br>Each member of fstack.items[0.. fstack.depth-1].font is a composite
<br>font and its descendant fonts can be accessed by described above. But
<br>contents of FDepVector are references to another gs_font objects.
<br>'fstack' is an array describing a single path of fonts those ware
<br>selected to 'show' current glyph. gs_type0_next_char_glyph() is
<br>called for each glyph to know if selected descendant font path has
<br>been changed for next glyph.
<br><br><br><br>> I'm puzzled as to the way these fonts are laid out, and would like
<br>> some education on the subject, pictures might be required ;-)
<br>>
<br>>
<br>>
<br>> Ken
<br><br>I am still learning things here. Those are the things I somehow
<br>managed to figure out so far.
<br><br>Thanks,
<br>Masaki
<br><br><br><br><br>_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26422413&i=0" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26422280Re: Image resolution not preserved2009-11-19T00:12:32Z2009-11-19T00:12:32ZKen SharpAt 14:04 18/11/2009 -0800, birksworks wrote:
<br><br><br>>The picture isn't distorted (i.e. the aspect ratio is visibly correct), so I
<br>>assume the different x/y scaling is hard coded by the Python software to
<br>>make up for rectangular screen pixels. Does that make sense? Is there a
<br>>better solution?
<br><br>Its not really anything to do with screen pixels or such. As I said in
<br>PostScript and PDF the image is nominally set on a 1x1 unit square, and the
<br>CTM is used to scale that 1x1 co-ordinate space to the desired actual coverage.
<br><br>If we did no scaling then your image would be placed in a square 1/72 of an
<br>inch on the side, and the resolution would be 594*72 = 42768 dpi in the x
<br>direction and 544*72 = 39168 dpi in the y direction. It would also of
<br>course be distorted ;-)
<br><br>The scaling is there so that the image covers the expected area, and also
<br>to make sure that it does have the correct aspect ratio. Its just the way
<br>that PostScript and PDF draw images.
<br><br><br><br> Ken
<br><br><br>_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26422280&i=0" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26416622Re: Image resolution not preserved2009-11-18T14:04:40Z2009-11-18T14:04:40ZbirksworksThanks for the detailed explanation! It's useful to understand exactly where things went wrong. We have forwarded them to the PDF Checkpoint developer. One last question:
<br><br>The picture isn't distorted (i.e. the aspect ratio is visibly correct), so I assume the different x/y scaling is hard coded by the Python software to make up for rectangular screen pixels. Does that make sense? Is there a better solution?
<br><br>Bob
<br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26410337Re: Proposal for changing semantics of gx_font_stack_item_t::index (bug #690834)2009-11-18T07:49:57Z2009-11-18T07:49:57ZKen SharpAt 22:42 18/11/2009 +0900, Masaki Ushizaka wrote:
<br><br><br>>fstack.items[0] is a rootfont. fstack.items[1 .. fstack.depth-1] are
<br>>intermediate composite fonts. And fstack.items[fstack.depth] is a
<br>>base font or a CIDFont. These are aligned in
<br>>gschar0.c:gs_type0_next_char_glyph().
<br><br>I have no objection to the patch, what I see looks sensible, and is the way
<br>I thought it worked anyway....
<br><br>I do have some questions about the existing scheme for my own education
<br>though if you don't mind answering them.
<br><br>fstack.items[0].font is a root font (type 0 composite font) currently
<br>fstack.items[0].index is always 0.
<br><br>You describe fstack.items[1 .. fstack.depth-1] (presumably the .font
<br>member ?) as 'intermediate composite fonts' are these type 0 composite
<br>fonts, or base fonts of some kind, or can it be either ?
<br><br>fstack.items[fstack.depth], again presumably the font member, is a base
<br>font or CIDFont. I can see what this means for CIDFonts, what is meant by a
<br>'base font', a type 0 or something else ?
<br><br><br>>Currently, 'index' member is used:
<br>> For n=0: fstack.items[0].index == 0 (not used)
<br>> For n=[1 .. fstack.depth]:
<br>> fstack.items[n].index == font number used in
<br>>fstack.items[n-1].font
<br>> (fstack.items[n-1].font.data.FDepVector[indexed by
<br>>fstack.items[n].index] == fstack.items[n].font)
<br><br>So this implies that each member of fstack.items[1...fstack.depth-1] is
<br>potentially a composite font with its own array of descendants ?
<br><br>It also seems to imply that when a composite font has composite
<br>descendants, the descendants have FDepVector arrays whose members are
<br>elements of the fstack array ?
<br><br>I'm puzzled as to the way these fonts are laid out, and would like some
<br>education on the subject, pictures might be required ;-)
<br><br><br><br> Ken
<br><br><br>_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26410337&i=0" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26409653Re: Proposal for changing semantics of gx_font_stack_item_t::index (bug #690834)2009-11-18T07:13:18Z2009-11-18T07:13:18ZRay JohnstonMasaki,
<br><br>I have not dug into the CIDFont processing for some time, but
<br>looking at your proposed change, this seems fine to me.
<br><br>Regards,
<br>Ray
<br>_________________________________________________________________
<br>Masaki Ushizaka wrote:
<div class='shrinkable-quote'><br>> Dear gs_devel,
<br>>
<br>> I want to change the way gx_font_stack_item_t::index is used, as part of
<br>> fixing bug #690834. This struct is used in gs_text_enum_t::fstack, and
<br>> is describing nesting composite-descendant font relationship.
<br>>
<br>> Currently, the 'index' member is used to describe a 'font number' of
<br>> this font in parent composite font. I want to change it to describe a
<br>> 'font number' of descendant font.
<br>> In a short, I want to move fstack.items[n].index to
<br>> fstack.items[n-1].index, to make a room for FDArray index for CIDFonts
<br>> in fstack.items[fstack.depth].index. Revision 3247 and 5613 assumed
<br>> fstack.items[fstack.depth].index was an FDArray index, I just want to
<br>> make it happen.
<br>>
<br>> This patch is however, just to make a room and
<br>> fstack.items[fstack.depth].index is always set to zero. Finding an
<br>> FDArray index itself is controversial procedure and I want to discuss it
<br>> in next proposal.
<br>>
<br>>
<br>> These are defined in gxtext.h.
<br>>
<br>> #define MAX_FONT_STACK 5
<br>> typedef struct gx_font_stack_item_s {
<br>> gs_font *font; /* font at this level */
<br>> uint index; /* index of this font in parent's Encoding */
<br>> } gx_font_stack_item_t;
<br>> typedef struct gx_font_stack_s {
<br>> int depth;
<br>> gx_font_stack_item_t items[1 + MAX_FONT_STACK];
<br>> } gx_font_stack_t;
<br>>
<br>> #define gs_text_enum_common\
<br>> ...
<br>> gx_font_stack_t fstack;\
<br>> ...
<br>>
<br>> struct gs_text_enum_s {
<br>> gs_text_enum_common;
<br>> };
<br>>
<br>> fstack.items[0] is a rootfont. fstack.items[1 .. fstack.depth-1] are
<br>> intermediate composite fonts. And fstack.items[fstack.depth] is a base
<br>> font or a CIDFont. These are aligned in
<br>> gschar0.c:gs_type0_next_char_glyph().
<br>>
<br>> Currently, 'index' member is used:
<br>> For n=0: fstack.items[0].index == 0 (not used)
<br>> For n=[1 .. fstack.depth]:
<br>> fstack.items[n].index == font number used in fstack.items[n-1].font
<br>> (fstack.items[n-1].font.data.FDepVector[indexed by
<br>> fstack.items[n].index] == fstack.items[n].font)
<br>>
<br>>
<br>> I want to change this relationship as follows:
<br>> For n=[0 .. fstack.depth-1]:
<br>> fstack.items[n].index == font number used in fstack.items[n].font
<br>> fstack.items[n].font.data.FDepVector[indexed by
<br>> fstack.items[n].index] == fstack.items[n+1].font
<br>> For n=fstack.depth:
<br>> If fstack.items[fstack.depth].font is a CIDFontType 0 CIDFont:
<br>> fstack.items[fstack.depth].index == index of FDArray font
<br>> If fstack.items[fstack.depth].font is another type of CIDFonts or
<br>> base fonts:
<br>> fstack.items[fstack.depth].index == 0 (not used)
<br>>
<br>>
<br>> Functions affected by this change will be:
<br>> gxchar.c:set_char_width()
<br>> gxchar.c:show_state_setup()
<br>> gxchar.c:gx_current_char()
<br>> gschar0.c:gs_type0_next_char_glyph() along with macro select_descendant()
<br>> gschar0.c:gs_stack_modal_fonts()
<br>> gdevpdtc.c:scan_cmap_text()
<br>>
<br>> First two functions are already assuming that
<br>> fstack.items[fstack.depth].index is an FDArray index.
<br>>
<br>>
<br>> This patch seems not making any differences. However, please let me
<br>> know if there are possibilities of flaws you might think of.
<br>>
<br>> Thank you,
<br>> Masaki Ushizaka
<br>>
<br>>
<br>>
<br>>
<br>> -----
<br>> Masaki Ushizaka
<br>> Artifex Software Inc. | <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26409653&i=0" target="_top" rel="nofollow">masaki.ushizaka@...</a>
<br>> phone +81.3.5468.7190 | cell +81.90.4027.4736 | fax +81.3.4496.6017
<br>> 302 Nakamura Bldg., 2-7-14 Shibuya, Shibuya-ku, Tokyo 150-0002 JAPAN
<br>>
<br>>
<br>>
<br>>
<br>> ------------------------------------------------------------------------
<br>>
<br>> _______________________________________________
<br>> gs-devel mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26409653&i=1" target="_top" rel="nofollow">gs-devel@...</a>
<br>> <a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a></div><br>_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26409653&i=2" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26407973Proposal for changing semantics of gx_font_stack_item_t::index (bug #690834)2009-11-18T05:42:35Z2009-11-18T05:42:35ZMasaki UshizakaDear gs_devel,
<br><br>I want to change the way gx_font_stack_item_t::index is used, as part
<br>of fixing bug #690834. This struct is used in gs_text_enum_t::fstack,
<br>and is describing nesting composite-descendant font relationship.
<br><br>Currently, the 'index' member is used to describe a 'font number' of
<br>this font in parent composite font. I want to change it to describe a
<br>'font number' of descendant font.
<br>In a short, I want to move fstack.items[n].index to
<br>fstack.items[n-1].index, to make a room for FDArray index for CIDFonts
<br>in fstack.items[fstack.depth].index. Revision 3247 and 5613 assumed
<br>fstack.items[fstack.depth].index was an FDArray index, I just want to
<br>make it happen.
<br><br>This patch is however, just to make a room and
<br>fstack.items[fstack.depth].index is always set to zero. Finding an
<br>FDArray index itself is controversial procedure and I want to discuss
<br>it in next proposal.
<br><br><br>These are defined in gxtext.h.
<br><br>#define MAX_FONT_STACK 5
<br>typedef struct gx_font_stack_item_s {
<br> gs_font *font; /* font at this level */
<br> uint index; /* index of this font in parent's Encoding */
<br>} gx_font_stack_item_t;
<br>typedef struct gx_font_stack_s {
<br> int depth;
<br> gx_font_stack_item_t items[1 + MAX_FONT_STACK];
<br>} gx_font_stack_t;
<br><br>#define gs_text_enum_common\
<br> ...
<br> gx_font_stack_t fstack;\
<br> ...
<br><br>struct gs_text_enum_s {
<br> gs_text_enum_common;
<br>};
<br><br>fstack.items[0] is a rootfont. fstack.items[1 .. fstack.depth-1] are
<br>intermediate composite fonts. And fstack.items[fstack.depth] is a
<br>base font or a CIDFont. These are aligned in
<br>gschar0.c:gs_type0_next_char_glyph().
<br><br>Currently, 'index' member is used:
<br> For n=0: fstack.items[0].index == 0 (not used)
<br> For n=[1 .. fstack.depth]:
<br> fstack.items[n].index == font number used in
<br>fstack.items[n-1].font
<br> (fstack.items[n-1].font.data.FDepVector[indexed by
<br>fstack.items[n].index] == fstack.items[n].font)
<br><br><br>I want to change this relationship as follows:
<br> For n=[0 .. fstack.depth-1]:
<br> fstack.items[n].index == font number used in fstack.items[n].font
<br> fstack.items[n].font.data.FDepVector[indexed by
<br>fstack.items[n].index] == fstack.items[n+1].font
<br> For n=fstack.depth:
<br> If fstack.items[fstack.depth].font is a CIDFontType 0 CIDFont:
<br> fstack.items[fstack.depth].index == index of FDArray font
<br> If fstack.items[fstack.depth].font is another type of CIDFonts
<br>or base fonts:
<br> fstack.items[fstack.depth].index == 0 (not used)
<br><br><br>Functions affected by this change will be:
<br>gxchar.c:set_char_width()
<br>gxchar.c:show_state_setup()
<br>gxchar.c:gx_current_char()
<br>gschar0.c:gs_type0_next_char_glyph() along with macro
<br>select_descendant()
<br>gschar0.c:gs_stack_modal_fonts()
<br>gdevpdtc.c:scan_cmap_text()
<br><br>First two functions are already assuming that
<br>fstack.items[fstack.depth].index is an FDArray index.
<br><br><br>This patch seems not making any differences. However, please let me
<br>know if there are possibilities of flaws you might think of.
<br><br>Thank you,
<br>Masaki Ushizaka
<br><br><br><br><br>-----
<br>Masaki Ushizaka
<br>Artifex Software Inc. | <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26407973&i=0" target="_top" rel="nofollow">masaki.ushizaka@...</a>
<br>phone +81.3.5468.7190 | cell +81.90.4027.4736 | fax +81.3.4496.6017
<br>302 Nakamura Bldg., 2-7-14 Shibuya, Shibuya-ku, Tokyo 150-0002 JAPAN
<br><br><br><br><br /> <br />_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26407973&i=1" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>b690834_p1.patch</strong> (4K) <a href="http://old.nabble.com/attachment/26407973/0/b690834_p1.patch" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26404672Re: Image resolution not preserved2009-11-18T01:16:51Z2009-11-18T01:16:51ZKen SharpAt 16:00 17/11/2009 -0800, birksworks wrote:
<br><br><br>>PDF Checkpoint says that output-few has images at 30dpi and that output-many
<br>>has images at 72dpi.
<br><br>And what does it say about input.pdf ?
<br><br>input.pdf specifies the image like this:
<br><br><<
<br>/ColorSpace /DeviceGray
<br>/Subtype /Image
<br>/Length 323135
<br>/Width 594
<br>/Type /XObject
<br>/BitsPerComponent 8
<br>/Height 544
<br> >>
<br><br>The amount of data is given by the Width and Height keys. This image is 594
<br>samples wide and 544 samples high. Notice that no resolution is given, the
<br>effective resolution of the image is given by seeing how large the area
<br>covered is.
<br><br>To start with in PostScript and PDF the image is assumed to cover the unit
<br>square, and then the current transformation matrix is applied to scale it
<br>into the desired output.
<br><br>In your case this is given as :
<br><br>142.5 0 0 130.5 0 2.072713 cm
<br><br>So your image is scaled anamorphically, by a factor of 142.5 in the x
<br>direction and 130.5 in the y direction. So your image now covers 142.5
<br>units by 130.5 units. PDF units (like PostScript) are 72 to the inch, so
<br>your image covers 1.98 inches by 1.81 inches (looks about right by visual
<br>inspection).
<br><br>I used the Acrobat Pro 9 measurement tools to verify this (screenshot
<br>attached).
<br><br>You image is therefore 594/1.98 = 300 dpi by 544/1.81 = 300.55 dpi.
<br>Confirming your resolution.
<br><br>Looking at output-few.pdf we see that the pdfwrite output is a little more
<br>complex, and involves concatenated CTM operations. However, the image is
<br>still defined as:
<br><br><<
<br>/ColorSpace /DeviceGray
<br>/Subtype /Image
<br>/Filter /FlateDecode
<br>/DecodeParms
<br><<
<br>/Columns 594
<br>/Predictor 15
<br> >>
<br>/Length 97092
<br>/Width 594
<br>/Height 544
<br>/BitsPerComponent 8
<br> >>
<br><br>It has the same dimensions as before, so pdfwrite has preserved the image
<br>resolution. Looking at the content stream we see:
<br><br>q 0.1 0 0 0.1 0 0 cm
<br>...
<br>...
<br>q 1425 0 0 1305 293.465 6261.06 cm
<br>/R14 Do
<br><br>The two cm operations are cumulative, so the actual CTM in force is :
<br>142.5 0 0 130.5 29.3465 626.106. The calculation is thus the same as above,
<br>and the resolution of the image is the same.
<br><br>Finally we look at output-many.pdf and we see the same image yet again:
<br><br><<
<br>/ColorSpace /DeviceGray
<br>/Subtype /Image
<br>/Filter /FlateDecode
<br>/DecodeParms
<br><<
<br>/Columns 594
<br>/Predictor 15
<br> >>
<br>/Length 97092
<br>/Width 594
<br>/Height 544
<br>/BitsPerComponent 8
<br> >>
<br><br>Because you have specified a resolution of 300 instead of the default 720
<br>the numbers are a little different in the content stream:
<br><br>q 0.24 0 0 0.24 0 0 cm
<br>...
<br>...
<br>q 593.75 0 0 543.75 122.277 2608.77 cm
<br>/R16 Do
<br><br>We concatenate the matrix operations as before, yielding a CTM of
<br>593 x 0.24 = 142.5
<br>0
<br>0
<br>543.75 x 0.24 = 130.5
<br>122.27 x 0.24 = 29.3448
<br>2608.77 x 0.24 = 626.1048
<br><br>The important values, the x and y scale are the same as the previous 2
<br>cases, and therefore the image has the same resolution, 300 dpi.
<br><br>Now, your PDF Checkpoint tool is out by a factor of 10 in the case of
<br>output-few.pdf, which is exactly the scale factor applied by the initial
<br>'cm' operation. In the case of output-many.pdf it is out by a factor of
<br>4.166 which is exactly the same as the scale factor in the initial 'cm'
<br>operation in that file (0.24).
<br><br>It seems clear to me that the application is *not* properly interpreting
<br>the PDF file, it looks like it is assuming that each 'cm' operation is
<br>atomic rather than cumulative and only seems to be tracking the last such
<br>operation. As a result it is applying only that matrix to the image to
<br>determine its resolution. It should be applying the combined effect of the
<br>matrices.
<br><br><br>> Of course, this could be a bug in PDF Checkpoint but
<br>>since we couldn't find many other checkers, we decided to be cautious. If
<br>>this checker gets it wrong (while getting others right), then perhaps other
<br>>apps in a printer's workflow will be confused too.
<br><br>The only app you should need to worry about is a PDF interpreter, since it
<br>will be guided by what's in the PDF file, it won't get confused. If it
<br>does, then its a bug in the application and you should report it to the
<br>authors. There isn't anything we can do about other people's bugs.
<br><br><br><br> Ken
<br><br>_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26404672&i=0" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26401606Re: Image resolution not preserved2009-11-17T18:49:31Z2009-11-17T18:49:31ZbirksworksI've added links to the three pdf file:
<br><br><a href="http://www.calcworks.net/pdf/input.pdf" target="_top" rel="nofollow">http://www.calcworks.net/pdf/input.pdf</a><br><a href="http://www.calcworks.net/pdf/output-few.pdf" target="_top" rel="nofollow">http://www.calcworks.net/pdf/output-few.pdf</a><br><a href="http://www.calcworks.net/pdf/output-many.pdf" target="_top" rel="nofollow">http://www.calcworks.net/pdf/output-many.pdf</a><br><br>Bob<p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26400088Re: Image resolution not preserved2009-11-17T16:00:56Z2009-11-17T18:47:06ZbirksworksI've uploaded three files. The first (<a href="http://www.calcworks.net/pdf/input.pdf" target="_top" rel="nofollow">http://www.calcworks.net/pdf/input.pdf</a>) is a small test file with images at 300dpi, the second (<a href="http://www.calcworks.net/pdf/output-few.pdf" target="_top" rel="nofollow">http://www.calcworks.net/pdf/output-few.pdf</a>) was obtained by running GhostScript on the input file with the following minimal options
<br><br>gs -sDEVICE=pdfwrite -q -dBATCH -dNOPAUSE -dSAFER -dPDFX -dPDFSETTINGS=/prepress -dEmbedAllFonts=true -dSubsetFonts=false -sOutputFile=output-few.pdf -f input.pdf -c quit
<br><br>and the third (<a href="http://www.calcworks.net/pdf/output-many.pdf" target="_top" rel="nofollow">http://www.calcworks.net/pdf/output-many.pdf</a>) was obtained by running GhostScript on the input file with the following many options
<br><br>gs -sDEVICE=pdfwrite -q -r300 -dBATCH -dNOPAUSE -dSAFER -dPDFX -dPDFSETTINGS=/prepress -dEmbedAllFonts=true -dSubsetFonts=false -dJPEGQ=100 -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dAutoFilterGrayImages=false -dGrayImageFilter=/FlateEncode -dUseFlateCompression=true -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -dMaxSubsetPct=100 -dAutoFilterMonoImages=false -dMonoImageFilter=/CCITTFaxEncode -dCompatibilityLevel=1.3 -dDownsampleColorImages=false -dDownsampleGrayImages=false -dDownsampleMonoImages=false -sOutputFile=output-many.pdf -f input.pdf -c quit
<br><br>PDF Checkpoint says that output-few has images at 30dpi and that output-many has images at 72dpi. Of course, this could be a bug in PDF Checkpoint but since we couldn't find many other checkers, we decided to be cautious. If this checker gets it wrong (while getting others right), then perhaps other apps in a printer's workflow will be confused too.
<br><br>Bob
<br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26383108Re: Image resolution not preserved2009-11-16T17:46:45Z2009-11-16T17:46:45ZbirksworksThanks for the help, Ken and dingodog.
<br><br>I should have mentioned that I'm using Ghostscript 8.64 on Ubuntu 9.10. I will create a simple test version of my file that reproduces the problem and make it available to the list.
<br><br>Bob<p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26339339Re: Image resolution not preserved2009-11-13T08:28:23Z2009-11-13T08:28:23ZKen SharpAt 07:55 13/11/2009 -0800, birksworks wrote:
<br><br><br>>but with no luck. Can anyone suggest a way to preserve image resolutions?
<br><br>Ghostscript already preserves images at their native resolution in general,
<br>and even when it does not (for example flattening transparency) it uses the
<br>specified resolution, in your case 300 dpi.
<br><br>How are you determining the image resolution of the original images, and
<br>the images in the created PDF file ?
<br><br>You don't say which version of Ghostscript you are using, nor which
<br>platform you are running on, and obviously you haven't supplied a test file
<br>for us to look at, its going to be pretty nearly impossible to help you
<br>without all that information. BTW you also don't seem to have discovered
<br>the image downsample controls 'xxxImageDownsampleThreshold' and
<br>'xxxImageDownsampleType'
<br><br>If you are using the latest version of Ghostscript, and are sure this is
<br>still a problem, then your best bet is to open a bug report at:
<br><br><a href="http://bugs.ghostscript.com" target="_top" rel="nofollow">http://bugs.ghostscript.com</a><br><br>Once the report is open you can attach files to it, if they are sensitive
<br>then you can mark them as private, which limits their availability to
<br>Artifex employees.
<br><br><br><br> Ken
<br><br>_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26339339&i=0" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26328064Image resolution not preserved2009-11-12T14:56:47Z2009-11-12T14:56:47ZbirksworksI'm using ghostscript to embed fonts in some existing pdf documents. The options
<br> -dEmbedAllFonts=true
<br> -dSubsetFonts=false
<br>do this for me but the images in the resulting pdf document have a lower resolution (72dpi) than those of the original document (300dpi). I've tried setting many options that could affect this:
<br><br> -sDEVICE=pdfwrite
<br> -q
<br> -r300
<br> -dBATCH
<br> -dNOPAUSE
<br> -dSAFER
<br> -dPDFX
<br> -dPDFSETTINGS=/prepress
<br> -dEmbedAllFonts=true
<br> -dSubsetFonts=false
<br> -dJPEGQ=100
<br> -dAutoFilterColorImages=false
<br> -dColorImageFilter=/FlateEncode
<br> -dAutoFilterGrayImages=false
<br> -dGrayImageFilter=/FlateEncode
<br> -dUseFlateCompression=true
<br> -dTextAlphaBits=4
<br> -dGraphicsAlphaBits=4
<br> -dMaxSubsetPct=100
<br> -dAutoFilterMonoImages=false
<br> -dMonoImageFilter=/CCITTFaxEncode
<br> -dCompatibilityLevel=1.3
<br><br>but with no luck. Can anyone suggest a way to preserve image resolutions?
<br><br>Thanks,
<br>Bob<p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26399052Libtiff performance2009-11-12T02:37:40Z2009-11-12T02:37:40ZLars UebernickelHi,
<br><br>I've done a bit of performance testing with the new TIFF devices (based
<br>on libtiff).
<br><br>I measured cpu time needed in user space for two documents at 300 dpi:
<br><br>* a document which only does showpage, to minimize the work done by the
<br>interpreter and renderer
<br>* tiger.eps, to compare the implementations of the tiff compression
<br>algorithms
<br><br>To get the confidence intervals into somehow sane levels, I did 20
<br>iterations for each device and implementation.
<br><br>The columns in the results are: mean, standard deviation, confidence
<br>interval (95%) and a relative comparison of the two versions (the
<br>slowest one being 100%). Note the relatively slow rendering times: my
<br>computer died a few weeks ago and I'm on an older machine (1.3Ghz
<br>athlon) right now.
<br><br>Unfortunately, libtiff seems to be slower in quite a few cases,
<br>especially for compressed files (see tiffg* and tiffcrle). It seems to
<br>be faster for lzw, though. It might be worthwhile to switch back to
<br>ghostscript's own compression in some cases.
<br><br>The python script I used to do these tests is attached.
<br><br>Please let me know what you think, or if I have overlooked anything ;)
<br><br> Lars
<br><br><br>Results for the white page:
<br><br>tiffgray
<br> new 0.304500 0.002233 0.299066 <= t <= 0.309934 100.00 %
<br> old 0.294500 0.001983 0.289673 <= t <= 0.299327 96.72 %
<br><br>tiff12nc
<br> new 0.531500 0.005906 0.517128 <= t <= 0.545872 100.00 %
<br> old 0.503500 0.006620 0.487390 <= t <= 0.519610 94.73 %
<br><br>tiff24nc
<br> new 0.420000 0.004413 0.409261 <= t <= 0.430739 100.00 %
<br> old 0.391500 0.004604 0.380296 <= t <= 0.402704 93.21 %
<br><br>tiff32nc
<br> new 0.443500 0.004429 0.432722 <= t <= 0.454278 100.00 %
<br> old 0.394000 0.005544 0.380509 <= t <= 0.407491 88.84 %
<br><br>tiffsep
<br> new 4.274500 0.032138 4.196293 <= t <= 4.352707 98.23 %
<br> old 4.351500 0.040758 4.252318 <= t <= 4.450682 100.00 %
<br><br>tiffcrle
<br> new 0.260000 0.001451 0.256469 <= t <= 0.263531 98.67 %
<br> old 0.263500 0.001094 0.260837 <= t <= 0.266163 100.00 %
<br><br>tiffg3
<br> new 0.267500 0.002891 0.260466 <= t <= 0.274534 98.53 %
<br> old 0.271500 0.003500 0.262983 <= t <= 0.280017 100.00 %
<br><br>tiffg32d
<br> new 0.264000 0.002103 0.258883 <= t <= 0.269117 97.24 %
<br> old 0.271500 0.002209 0.266123 <= t <= 0.276877 100.00 %
<br><br>tiffg4
<br> new 0.264500 0.001846 0.260008 <= t <= 0.268992 96.18 %
<br> old 0.275000 0.002565 0.268758 <= t <= 0.281242 100.00 %
<br><br>tifflzw
<br> new 0.272500 0.001758 0.268221 <= t <= 0.276779 85.83 %
<br> old 0.317500 0.001602 0.313602 <= t <= 0.321398 100.00 %
<br><br>tiffpack
<br> new 0.276000 0.003195 0.268224 <= t <= 0.283776 99.82 %
<br> old 0.276500 0.004369 0.265867 <= t <= 0.287133 100.00 %
<br><br><br><br>Results for tiger.eps:
<br><br>tiffgray
<br> new 0.574500 0.004892 0.562595 <= t <= 0.586405 99.91 %
<br> old 0.575000 0.005781 0.560932 <= t <= 0.589068 100.00 %
<br><br>tiff12nc
<br> new 0.870000 0.002991 0.862721 <= t <= 0.877279 100.00 %
<br> old 0.820000 0.004920 0.808026 <= t <= 0.831974 94.25 %
<br><br>tiff24nc
<br> new 0.749500 0.003733 0.740416 <= t <= 0.758584 100.00 %
<br> old 0.728500 0.004547 0.717436 <= t <= 0.739564 97.20 %
<br><br>tiff32nc
<br> new 0.867000 0.003411 0.858701 <= t <= 0.875299 100.00 %
<br> old 0.832500 0.005020 0.820285 <= t <= 0.844715 96.02 %
<br><br>tiffsep
<br> new 4.738000 0.010428 4.712625 <= t <= 4.763375 99.03 %
<br> old 4.784500 0.012576 4.753898 <= t <= 4.815102 100.00 %
<br><br>tiffcrle
<br> new 0.659500 0.002112 0.654361 <= t <= 0.664639 100.00 %
<br> old 0.576000 0.002224 0.570587 <= t <= 0.581413 87.34 %
<br><br>tiffg3
<br> new 0.660000 0.001919 0.655329 <= t <= 0.664671 100.00 %
<br> old 0.576500 0.002209 0.571123 <= t <= 0.581877 87.35 %
<br><br>tiffg32d
<br> new 0.866000 0.003026 0.858636 <= t <= 0.873364 100.00 %
<br> old 0.714000 0.002938 0.706851 <= t <= 0.721149 82.45 %
<br><br>tiffg4
<br> new 0.965000 0.002856 0.958050 <= t <= 0.971950 100.00 %
<br> old 0.736000 0.002340 0.730307 <= t <= 0.741693 76.27 %
<br><br>tifflzw
<br> new 0.547000 0.001792 0.542640 <= t <= 0.551360 90.86 %
<br> old 0.602000 0.001717 0.597822 <= t <= 0.606178 100.00 %
<br><br>tiffpack
<br> new 0.532500 0.002036 0.527546 <= t <= 0.537454 100.00 %
<br> old 0.530500 0.002112 0.525361 <= t <= 0.535639 99.62 %
<br><br /> <br />_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26399052&i=0" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>compareperformance.tar.gz</strong> (7K) <a href="http://old.nabble.com/attachment/26399052/0/compareperformance.tar.gz" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26244850Re: Convert PDF to PS - Automatic page rotation to Portrait2009-11-07T05:25:57Z2009-11-07T05:25:57ZKen SharpAt 13:21 07/11/2009 +0100, Lakos Dániel wrote:
<br><br><br>>with '-sDevice=pswrite' the output page size is correct A4 (8.26 x 11.69
<br>>inches) -- characters and page size are OK.
<br><br>Yes, sorry I meant A4, no letter previously.
<br><br><br>>using '-sDevice=ps2write' the output 8.50 x 11.00 inches -- charachters ar
<br>>ok, but the document doesnt fit
<br><br>8.5x11 is Letter size.
<br><br><br>>It seems that the code i using (device=pswrite) is correctly convert the
<br>>pdf to ps (checked using adobe distiller).
<br>>When Hylafax conerts this PS to Tiff, things go wrong.
<br><br>Goes wrong how ? Can you run the produced PostScript file back through
<br>Ghostscript, and the output is correct ?
<br><br>You can have Ghostscript create a TIFF file for you if that's all you want,
<br>and you can do it from the original PDF.
<br><br><br>>How to get ps2write working with the correct papersize?
<br>>I hope the output of ps2write is going to give better results when
<br>>converted to tiff.
<br><br>Sounds like your system may be defaulting to letter media.
<br>You could try -sPAPERSIZE=a4 -dFIXEDMEDIA also -sDEFAULTPAPERSIZE=a4
<br><br><br> Ken
<br>_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26244850&i=0" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26244263Re: Convert PDF to PS - Automatic page rotation to Portrait2009-11-07T04:21:03Z2009-11-07T04:21:03ZLakos DánielKen Sharp írta:
<div class='shrinkable-quote'><br>> At 11:23 07/11/2009 +0100, =?ISO-8859-2?Q?Lakos_D=E1niel?= wrote:
<br>>
<br>>> Ive found a solution in the GS archives, and the rotation works as it
<br>>> should, but some text are malformed/characters missing after conversion.
<br>>> Does Anybody have an idea whats wrong?
<br>>> Is there any other method to "auto rotate" pages?
<br>>> My GhostScript Version is 8.15.
<br>>
<br>> First suggestion, upgrade to something more recent. The current
<br>> version is 8.70 and 8.15 is quite old.
<br>>
<br>> You might also consider using ps2write instead of pswrite as ps2write
<br>> generally does a better job.
<br>>
<br>> By the way, the code you are using only auto-rotates pages if they are
<br>> landscape letter (842x595 points), other page sizes may be scaled
<br>> and/or centered.
<br>>
<br>> Ken
<br>>
<br>>
<br>>
</div>Thank you for taking time to answer.
<br><br>I upgraded to 8.70.
<br>with '-sDevice=pswrite' the output page size is correct A4 (8.26 x 11.69 inches) -- characters and page size are OK.
<br>using '-sDevice=ps2write' the output 8.50 x 11.00 inches -- charachters ar ok, but the document doesnt fit
<br><br>As I know the 842x592 points are correct for A4 papersize.
<br><br>It seems that the code i using (device=pswrite) is correctly convert the pdf to ps (checked using adobe distiller).
<br>When Hylafax conerts this PS to Tiff, things go wrong.
<br><br>How to get ps2write working with the correct papersize?
<br>I hope the output of ps2write is going to give better results when converted to tiff.
<br><br>_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26244263&i=0" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26243952Re: Convert PDF to PS - Automatic page rotation to Portrait2009-11-07T03:31:43Z2009-11-07T03:31:43ZKen SharpAt 11:23 07/11/2009 +0100, =?ISO-8859-2?Q?Lakos_D=E1niel?= wrote:
<br><br>>Ive found a solution in the GS archives, and the rotation works as it
<br>>should, but some text are malformed/characters missing after conversion.
<br>>Does Anybody have an idea whats wrong?
<br>>Is there any other method to "auto rotate" pages?
<br>>My GhostScript Version is 8.15.
<br><br>First suggestion, upgrade to something more recent. The current version is
<br>8.70 and 8.15 is quite old.
<br><br>You might also consider using ps2write instead of pswrite as ps2write
<br>generally does a better job.
<br><br>By the way, the code you are using only auto-rotates pages if they are
<br>landscape letter (842x595 points), other page sizes may be scaled and/or
<br>centered.
<br><br> Ken
<br>_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26243952&i=0" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26243552Convert PDF to PS - Automatic page rotation to Portrait2009-11-07T02:23:18Z2009-11-07T02:23:18ZLakos DánielHi,
<br><br>Im using Hylafax, which can only send portrait documents, but theres a
<br>need to fax landscape PDFs as well.
<br>So I need a solution to detect page orientation and rotate the document
<br>to portrait, if its landscape.
<br>Portrait pages should be left alone...
<br><br>Ive found a solution in the GS archives, and the rotation works as it
<br>should, but some text are malformed/characters missing after conversion.
<br>Does Anybody have an idea whats wrong?
<br>Is there any other method to "auto rotate" pages?
<br>My GhostScript Version is 8.15.
<br><br>Thank You in Advance,
<br>Daniel
<br><br>The solution I use, is the following.
<br>-----------------------------------------------------------------------------
<br>gs -sOutputFile=out.ps \
<br> -sDEVICE=pswrite \
<br> -dBATCH -dNOPAUSE -dSAFER=true \
<br> autorotate.ps \
<br> in.pdf
<br>-----------------------------------------------------------------------------
<br>autorotate.ps:::::
<br>%!PS
<br> % Sequence to set up for a single page size, auto fit all pages.
<br> << /Policies << /PageSize 3 >>
<br> /InputAttributes currentpagedevice /InputAttributes get %current
<br>dict
<br> dup { pop 1 index exch undef } forall % remove all page sizes
<br> dup 0 << /PageSize [ 595 842 ] >> put % for A4 use [ 595 842 ]
<br> >> setpagedevice
<br>-----------------------------------------------------------------------------
<br>
<br><br><br>_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26243552&i=0" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26173782make so fails on Mac OS X2009-11-02T17:41:18Z2009-11-02T17:41:18ZMatt BroughtonI checked out revision 10257 with svn and tried to do a 'make so'
<br>under Mac OS X. The 'make so' fails with undefined symbols. This is
<br>the case for building x86_64 under OS X 10.6.1 and ppc under OS X
<br>10.4.11.
<br><br>A standard 'make' works fine.
<br><br>I am not sure if I missed something in patching the unix-dll.mak file
<br>or if there is something else going on. Any help would be
<br>appreciated.
<br><br><br>I patched the unix-dll.mak as follows:
<br>--- gs/base/unix-dll.mak.orig 2009-11-02 11:46:37.000000000 -0600
<br>+++ gs/base/unix-dll.mak 2009-11-02 11:50:33.000000000 -0600
<br>@@ -52,13 +52,13 @@
<br> LDFLAGS_SO=-shared -Wl,-soname=$(GS_SONAME_MAJOR)
<br><br> # MacOS X
<br>-#GS_SOEXT=dylib
<br>-#GS_SONAME=$(GS_SONAME_BASE).$(GS_SOEXT)
<br>-#GS_SONAME_MAJOR=$(GS_SONAME_BASE).$(GS_VERSION_MAJOR).$(GS_SOEXT)
<br>-#GS_SONAME_MAJOR_MINOR=$(GS_SONAME_BASE).$(GS_VERSION_MAJOR).$(GS_VERSION_MINOR).$(GS_SOEXT)
<br>-#LDFLAGS_SO=-dynamiclib -flat_namespace
<br>-#LDFLAGS_SO=-dynamiclib -install_name $(GS_SONAME_MAJOR_MINOR)
<br>-#LDFLAGS_SO=-dynamiclib -install_name $(FRAMEWORK_NAME)
<br>+GS_SOEXT=dylib
<br>+GS_SONAME=$(GS_SONAME_BASE).$(GS_SOEXT)
<br>+GS_SONAME_MAJOR=$(GS_SONAME_BASE).$(GS_VERSION_MAJOR).$(GS_SOEXT)
<br>+GS_SONAME_MAJOR_MINOR=$(GS_SONAME_BASE).$(GS_VERSION_MAJOR).$(GS_VERSION_MINOR).$(GS_SOEXT)
<br>+LDFLAGS_SO=-dynamiclib -flat_namespace
<br>+LDFLAGS_SO=-dynamiclib -install_name $(GS_SONAME_MAJOR_MINOR)
<br>+LDFLAGS_SO=-dynamiclib -install_name $(FRAMEWORK_NAME)
<br><br> GS_SO=$(BINDIR)/$(GS_SONAME)
<br> GS_SO_MAJOR=$(BINDIR)/$(GS_SONAME_MAJOR)
<br><br><br>I used the following autogen command:
<br>./autogen.sh --without-x --enable-cups --with-ijs --with-drivers=ALL
<br><br>With OS X 10.6.1, the failure is:
<br>Total %rom% structure size is 7397508 bytes.
<br>gcc -DHAVE_MKSTEMP -DHAVE_HYPOT -O2 -Wall -Wstrict-prototypes
<br>-Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings
<br>-Wno-strict-aliasing -Wdeclaration-after-statement -fno-builtin
<br>-fno-common -DHAVE_STDINT_H -DGX_COLOR_INDEX_TYPE="unsigned long int"
<br>-I./obj/../soobj -I./base -o ./obj/../soobj/gsromfs1.o -c
<br>./obj/../soobj/gsromfs1.c
<br>./obj/../soobj/echogs -w ./obj/../soobj/ldt.tr -n - gcc -dynamiclib
<br>-install_name -o ./bin/../sobin/libgs.8.71.dylib
<br>./obj/../soobj/echogs -a ./obj/../soobj/ldt.tr -n -s
<br>./obj/../soobj/gsromfs1.o ./obj/../soobj/gs.o -s
<br>cat ./obj/../soobj/ld.tr >>./obj/../soobj/ldt.tr
<br>./obj/../soobj/echogs -a ./obj/../soobj/ldt.tr -s - -ldl -lm -liconv
<br>-lstdc++ -lpthread -lm
<br>if [ x != x ]; then LD_RUN_PATH=; export LD_RUN_PATH; fi; \
<br> XCFLAGS= XINCLUDE= XLDFLAGS= XLIBDIRS= XLIBS= \
<br> FEATURE_DEVS= DEVICE_DEVS= DEVICE_DEVS1= DEVICE_DEVS2= DEVICE_DEVS3= \
<br> DEVICE_DEVS4= DEVICE_DEVS5= DEVICE_DEVS6= DEVICE_DEVS7= DEVICE_DEVS8= \
<br> DEVICE_DEVS9= DEVICE_DEVS10= DEVICE_DEVS11= DEVICE_DEVS12= \
<br> DEVICE_DEVS13= DEVICE_DEVS14= DEVICE_DEVS15= DEVICE_DEVS16= \
<br> DEVICE_DEVS17= DEVICE_DEVS18= DEVICE_DEVS19= DEVICE_DEVS20= \
<br> DEVICE_DEVS_EXTRA= \
<br> /bin/sh <./obj/../soobj/ldt.tr
<br>Undefined symbols:
<br> "_gs_romfs_buildtime", referenced from:
<br> _romfs_file_status in gsiorom.o
<br> "_gs_romfs", referenced from:
<br> _romfs_open_file in gsiorom.o
<br> _romfs_file_status in gsiorom.o
<br> _romfs_enumerate_next in gsiorom.o
<br>ld: symbol(s) not found
<br>collect2: ld returned 1 exit status
<br>make[1]: *** [bin/../sobin/libgs.8.71.dylib] Error 1
<br>make: *** [so] Error 2
<br><br>--
<br>Matt Broughton
<br>Only relatives are absolute.
<br>_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26173782&i=0" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26164135Re: xref error under Mac OS X2009-11-02T05:51:54Z2009-11-02T05:51:54ZMatt BroughtonAt 1:18 PM -0500 11/1/09, Alex Cherepanov wrote:
<div class='shrinkable-quote'><br>>Matt Broughton wrote:
<br>>> Sample PDF is at
<br>>><<a href="http://webpages.charter.net/mbroughtn/beta/cgpdftopdfOUT.pdf" target="_top" rel="nofollow">http://webpages.charter.net/mbroughtn/beta/cgpdftopdfOUT.pdf</a>>.
<br>>>This is the output from the running of Apple's cgpdftopdf filter on
<br>>>a PDF spool file. This is the normal Apple printing workflow.
<br>>>Ghostscript is indicating there is an error. Apple believes the
<br>>>PDF is compliant.
<br>>The file is invalid. The file has no object 11 and this is OK.
<br>>However, xref entry for the object 11 places it at the position 0.
<br>> 0000000000 00000 n
<br>>
<br>>Ghostscript validates xref table and complains about this entry.
<br>>Ghostscript also chooses rebuild the whole table, which is not needed
<br>>in this case. The table is valid except one insignificant entry.
<br>>
<br>>According to the spec, free entries should form a linked list.
</div>. . .
<br><br>>Ghostscript doesn't validate the linked list. It just ignores all free
<br>>entries regardless of the numbers, but free entries should have 'f'
<br>>keyword.
<br><br><br>Thank you for the very detailed explanation.
<br>--
<br>Matt Broughton
<br>Only relatives are absolute.
<br>_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26164135&i=0" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26153394Re: xref error under Mac OS X2009-11-01T10:18:05Z2009-11-01T10:18:05ZAlex CherepanovMatt Broughton wrote:
<br>> Sample PDF is at
<br>> <<a href="http://webpages.charter.net/mbroughtn/beta/cgpdftopdfOUT.pdf" target="_top" rel="nofollow">http://webpages.charter.net/mbroughtn/beta/cgpdftopdfOUT.pdf</a>>. This is
<br>> the output from the running of Apple's cgpdftopdf filter on a PDF spool
<br>> file. This is the normal Apple printing workflow. Ghostscript is
<br>> indicating there is an error. Apple believes the PDF is compliant.
<br>The file is invalid. The file has no object 11 and this is OK.
<br>However, xref entry for the object 11 places it at the position 0.
<br> 0000000000 00000 n
<br><br>Ghostscript validates xref table and complains about this entry.
<br>Ghostscript also chooses rebuild the whole table, which is not needed
<br>in this case. The table is valid except one insignificant entry.
<br><br>According to the spec, free entries should form a linked list.
<br>0000000011 65535 f
<br>0000035459 00000 n
<br>0000002647 00000 n
<br>0000005659 00000 n
<br>0000000022 00000 n
<br>0000002627 00000 n
<br>0000002751 00000 n
<br>0000005623 00000 n
<br>0000009976 00000 n
<br>0000018475 00000 n
<br>0000032076 00000 n
<br>0000000000 00000 f
<br>...
<br><br>Ghostscript doesn't validate the linked list. It just ignores all free
<br>entries regardless of the numbers, but free entries should have 'f'
<br>keyword.
<br><br>Regards,
<br>Alex Cherepanov
<br>_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26153394&i=0" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26152285Re: xref error under Mac OS X2009-11-01T08:06:23Z2009-11-01T08:06:23ZMartin Schröder2009/11/1 Matt Broughton <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26152285&i=0" target="_top" rel="nofollow">walterwego@...</a>>:
<br>> I would ask that someone please take a look give an opinion/statement as to
<br>> whether there is a bug in Ghostscript or Apple's filter.
<br><br>The latter. Where is object 11?
<br><br>Best
<br> Martin
<br><br>PS: I can't recommend qpdf enough.
<br>_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26152285&i=1" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26152262xref error under Mac OS X2009-11-01T08:02:42Z2009-11-01T08:02:42ZMatt BroughtonSample PDF is at
<br><<a href="http://webpages.charter.net/mbroughtn/beta/cgpdftopdfOUT.pdf" target="_top" rel="nofollow">http://webpages.charter.net/mbroughtn/beta/cgpdftopdfOUT.pdf</a>>. This
<br>is the output from the running of Apple's cgpdftopdf filter on a PDF
<br>spool file. This is the normal Apple printing workflow. Ghostscript
<br>is indicating there is an error. Apple believes the PDF is compliant.
<br><br>I would ask that someone please take a look give an opinion/statement
<br>as to whether there is a bug in Ghostscript or Apple's filter.
<br><br>$ gs -v
<br>GPL Ghostscript 8.70 (2009-07-31)
<br>Copyright (C) 2009 Artifex Software, Inc. All rights reserved.
<br><br>$ gs -dFirstPage=1 -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE
<br>-sDEVICE=ijs -sIjsServer=hpijs -sDeviceManufacturer="HEWLETT-PACKARD"
<br>-sDeviceModel="DESKJET 870" -dDEVICEWIDTHPOINTS=612
<br>-dDEVICEHEIGHTPOINTS=792 -r300
<br>-sIjsParams=Quality:Quality=0,Quality:ColorMode=2,Quality:MediaType=0,Quality:PenSet=2
<br>-dIjsUseOutputFD -sOutputFile=testOut.prn cgpdftopdfOUT.pdf
<br> **** Warning: File has an invalid xref entry: 11. Rebuilding xref table.
<br><br> **** This file had errors that were repaired or ignored.
<br> **** The file was produced by:
<br> **** >>>> Mac OS X 10.6 Quartz PDFContext <<<<
<br> **** Please notify the author of the software that produced this
<br> **** file that it does not conform to Adobe's published PDF
<br> **** specification.
<br><br>--
<br>Matt Broughton
<br>Only relatives are absolute.
<br>_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26152262&i=0" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26037283Re: Ps to pdf problem2009-10-24T02:09:52Z2009-10-24T02:09:52Zyvan rousselHi,
<br><br>It's not a bug.
<br>You need to know at first the size of your eps.
<br>gswin32c -sDEVICE=bbox -dNOPAUSE -dBATCH "d:\testing\test.ps" > size.txt
<br>The size is in the file size.txt
<br>Then you do the pdf with the good size (width and height)
<br>gswin32c -dDEVICEWIDTHPOINTS=width -dDEVICEHEIGHTPOINTS=height -sDEVICE=pdfwrite -dNOPAUSE -dBATCH -sOutputFile="d:\testing\test.pdf" "d:\testing\test.ps"
<br>regards
<br>Y.Roussel
<br><br><br><blockquote class="quote light-black dark-border-color"><div class="quote light-border-color">
<div class="quote-author" style="font-weight: bold;">Gerald Manickam wrote:</div>
<div class="quote-message shrinkable-quote">Hi Friends,
<br><br> I used batch file pstopdf1.4 present in lib folder of Ghostscript 8.14. I passed arguments like the below.
<br><br> ps2pdf13 "D:\testing\test.ps" "D:\testing\testing.pdf"
<br><br> The output pdf file is cropped to A4 size. [612 X 792]. My aim is to get the full page size. when i checked the distiller the default size is A4. I do know how to set the original page size. Please tell me how to get the full page size.
<br><br>Thanks and Regards,
<br>Gerald Manickam Philiph
</div>
</div></blockquote>
<p>From forum: <a href="http://old.nabble.com/Ghostscript---bugs-f1630.html" embed="fixTarget[1630]" target="_top" >Ghostscript - bugs</a></p>tag:old.nabble.com,2006:post-26034202PDFWRITE convert CMYK to RVB2009-10-23T15:36:46Z2009-10-23T15:36:46Zyvan rousselHi,
<br><br>When I convert my EPS file with a CMYK image embedded to PDF,it becomes RVB!
<br>I want a PDF with CMYK.
<br>How can I do ?
<br><br>Here is the command :
<br>gswin32c -q -dNoPause -dSAFER -dNOPAUSE -dBATCH -dDEVICEWIDTHPOINTS=412 -dDEVICEHEIGHTPOINTS=511 -sDEVICE=pdfwrite -sOutputFile="9510448322.pdf" -f "9510448322.eps"
<br><br>Thank's
<br><br>Y.Roussel<p>From forum: <a href="http://old.nabble.com/Ghostscript---bugs-f1630.html" embed="fixTarget[1630]" target="_top" >Ghostscript - bugs</a></p>tag:old.nabble.com,2006:post-26023008Unable to decode JPX image data - Ghostscript 8.702009-10-23T02:03:42Z2009-10-23T02:03:42ZLexLuthorGhostscript - PDF to JPG - Linux Cent OS
<br><br>We have problems converting this pdf <a href="http://pdf.kewl.se/view/test/120/120.pdf" target="_top" rel="nofollow">http://pdf.kewl.se/view/test/120/120.pdf</a><br><br>This is the command we use today
<br>/usr/bin/gs -I/usr/share/fonts/default/Type1 -dPARANOIDSAFER -dBATCH -dNOPAUSE -dNOPROMPT -sDEVICE=png16m -dUseCIEColor -dFirstPage=1 -dLastPage=1 -r300x300 -sOutputFile=page.png 120.pdf
<br><br><br>The error we get is
<br><br>--------------------------------------------------------------------------------------
<br><br>GPL Ghostscript 8.70 (2009-07-31)
<br>Copyright (C) 2009 Artifex Software, Inc. All rights reserved.
<br>This software comes with NO WARRANTY: see the file PUBLIC for details.
<br>Processing pages 1 through 1.
<br>Page 1
<br>error: cannot decode code stream
<br>unable to decode JPX image data.
<br><br>**** Warning: File has insufficient data for an image.
<br><br>**** This file had errors that were repaired or ignored.
<br>**** The file was produced by:
<br>**** Adobe PDF Library 8.0
<br>**** Please notify the author of the software that produced this
<br>**** file that it does not conform to Adobe's published PDF
<br>**** specification.
<br><br>----------------------------------------------------------------------------------------
<br><br>Our setup
<br>- We have a Linux CentOS server where ghostscript is installed
<br><br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>tag:old.nabble.com,2006:post-26015285strange font splitting in -sDEVICE=pdfwrite2009-10-22T11:50:26Z2009-10-22T11:50:26ZPéter SzabóHi,
<br><br>Thank you for the informative and detailed response. Based your answer
<br>I was able to simulate `glyphshow' using `show' and the Encoding
<br>array. This solved my problem.
<br><br>Best regards,
<br><br>Péter
<br>_______________________________________________
<br>gs-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26015285&i=0" target="_top" rel="nofollow">gs-devel@...</a>
<br><a href="http://www.ghostscript.com/mailman/listinfo/gs-devel" target="_top" rel="nofollow">http://www.ghostscript.com/mailman/listinfo/gs-devel</a><br><p>From forum: <a href="http://old.nabble.com/Ghostscript---Dev-f1635.html" embed="fixTarget[1635]" target="_top" >Ghostscript - Dev</a></p>