View All Add an attachment proposed patch, testcase, etc. Comment 2 Need Real Name UTC Created attachment [details] printconf-tui --Xexport attached file, does everthing normally go through ghostscript to generate the. As I am getting a much larger printer queue size when printing all files. The problem arises from the printer having to keep an entire page in memory before any ink can touch the page. I would suggest either: a buy more memory for the PostScript module in your printer, or b try a raster-based driver instead, such as gimp-print-ijs or hpijs you can do this by going to the "Printer driver" tab in the edit print queue dialog.
Maybe it is regenerating the PS file as 1 big image instead of text and images? Maybe it is generating postscript at a high resolution without taking into account the resolution of images in the original file? I don't know enough about it to tell I am sure I can't be the first person to raise this as an issue what do other companies do?
Or is it just slow? Comment 6 Need Real Name UTC either way the ps file and queue sent to the printer is large, the out of memory error on the printer is dependent on the printer used though. After which some of them are small and some are huge. For example:. Probably a problem with the original PDF, but what exactly I can not understand. I can send the source files, just where? The problem here is due to a limitation of the ps2write device, and a quirk of the way the files are created.
What it does is render the glyph shapes to bitmaps, and construct type 3 bitmap fonts, which it then uses in the body of the PostScript program. This is, of course, less than ideal, as bitmap fonts are poorer quality than vector descriptions of the glyph shapes. Since you've fixed the rendering at dpi, that reduces the quality of the glyph bitmaps, but they should be acceptable for printing on a desktop printer.
So, given that both files contain CIDFonts, why is one much larger? This is the 'quirk' of the way the files are created. The file test1. Fonts can only address up to glyphs, while CIDFonts have a more or less unlimited range.
When ps2write creates type 3 fonts to represent the embedded CIDFonts, it can't create a Font which has the full addressable range that a CIDFont would, so if more than glyphs are used from a given font, it has to create multiple type 3 fonts.
So we fill up the font as we go, until we reach glyphs, then we start a new font. The problem is that if we then encounter a glyph that was used earlier, and therefore defined in a previous font, we can't simply switch fonts this is a limitation of the way ps2write works. So we have to include that glyph in the font we are currently creating as well.
This means we end up with two copies of the bitmap in the output; one for the first font that uses it and one for the second font. And that's exactly what is happening here. There is nothing you can do about that, unless you can control the production of the input PDF files, so the question then becomes 'is this a problem for you, and if so, why?
Well I doubt the size has any real impact on the printing time. For instance, simple figures often have labels or captions. If the font used for this is not in the standard PostScript font families of. This adds anywhere from kB per font in some cases just to print a single letter!! Some poorly-written software will even include all the standard fonts as well. This is intolerable, since every PostScript interpreter is required to have these four font families built-in already.
If you find non-standard fonts present i. If you find font information for the standard fonts, you can safely slim down your file by removing them. After making any modifications you will want to check that your file still prints and views correctly, just in case any accidents occurred while editing the file. Some applications, particularly on Macs and PCs, include a large uncompressed "preview" bitmap in every postscript file.
0コメント