summaryrefslogtreecommitdiff
path: root/gs
Commit message (Collapse)AuthorAgeFilesLines
* Update the release notes for the licensing change.Ralph Giles2009-07-303-8/+11
| | | | git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9909 a1074d23-0009-0410-80fe-cf8c14f379e6
* Relicense GPL Ghostscript under the GPLv3 or later.Ralph Giles2009-07-302-292/+626
| | | | git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9908 a1074d23-0009-0410-80fe-cf8c14f379e6
* Update change logs for 8.70rc1.Ralph Giles2009-07-285-5508/+11223
| | | | git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9906 a1074d23-0009-0410-80fe-cf8c14f379e6
* Update release version and date for 8.70rc1.Ralph Giles2009-07-2856-73/+73
| | | | git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9905 a1074d23-0009-0410-80fe-cf8c14f379e6
* Document the cat.ps utility.Ralph Giles2009-07-281-0/+6
| | | | git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9904 a1074d23-0009-0410-80fe-cf8c14f379e6
* Add release notes for 8.70rc1.Ralph Giles2009-07-281-468/+91
| | | | git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9903 a1074d23-0009-0410-80fe-cf8c14f379e6
* Change the operand types of encode_binary_token() to match theAlex Cherepanov2009-07-282-6/+6
| | | | | | | | | the type of PostScript integers in the ref structure. Bug 690660. DIFFERENCES: None. git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9902 a1074d23-0009-0410-80fe-cf8c14f379e6
* Bump the release number to 8.70.Ralph Giles2009-07-283-6/+6
| | | | | | The numerous transparency and smask fixes justify a new minor number. git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9900 a1074d23-0009-0410-80fe-cf8c14f379e6
* Fix incorrect right shift on 64-bit platforms. PLRM defines bitshift operatorAlex Cherepanov2009-07-281-4/+2
| | | | | | | | | | | as a logical shift. On 64-bit platform, the integer operand was promoted to 64-bit long value, shifted, and assigned back to 32-bit int, effectively emulating the sign extension. DIFFERENCES: Progression in 26-02.PS on 64-bit platforms. There's no other differences. git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9899 a1074d23-0009-0410-80fe-cf8c14f379e6
* Work around problems with XInitImage and large rasters.Ralph Giles2009-07-281-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch from Russ Cox, fixes Bugs 689547 and 689561. Details: The patch sets bitmap_pad, and passes 0 for bytes_per_line in cases were current xorg can correctly generate a value. Russ writes: I have tracked down the problem, and it appears to be a bad interaction between gs and recent sanity checking in the X library. In particular, sometimes x_copy_image in gdevx.c gets called with wide widths but narrow raster values. Even though the raster is apparently wrong, the X graphics operations would work okay with that value. But new versions of X11 have various checks in XInitImage, one of which is that the raster is greater than or equal to the width of the image times the depth. To see that this diagnosis is correct, replacing the call to XInitImage with a call to _XInitImageFuncPtrs (which is just XInitImage without the sanity checking) makes gs start working. But of course _XInitImageFuncPtrs is not a public interface function and thus probably not the best fix. Replacing the "bytes_per_line = raster" with "bytes_per_line = 0" (which makes X compute the value from width and depth) works fine in the zoom levels that would otherwise crash but causes the previously-working zoom levels to shear the image (or worse), presumably because the "obvious" raster is not the right one at those levels. Also, the new XInitImage also requires bitmap_pad be set always. The patch below also fixes the problem -- I can run "gv pprof.ps" at all zoom levels, and I can also zoom into regular documents. Perhaps it is not the right fix -- perhaps the actual bug is that x_copy_image is being called with a bad raster value in the first place. But it does work. git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9898 a1074d23-0009-0410-80fe-cf8c14f379e6
* Fix (pdfwrite): Excessive redefinitions of CIDFonts causing memory exhaustionKen Sharp2009-07-282-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Details: bug #690642: "conversion to PDF aborts after 800 pages" When instantiating a CIDFont with TrueType outlines, the TrueType interpretation code tries to name the font using the name table from the TrueType font. If there is no name table (as is the case for CIDFonts with TT outlines) it instead uses the XUID as the name. The XUID is incremented on every use, this means that each time the font is instantiated (up to once per page when the job is PDF) we create a new CIDFont with a new name. pdfwrite is unable to determine that these are all in fact the same original font, and creates many fonts in the output file, eventually leading to memory exhaustion. This change creates a new key in the current dictionary '/PDFCIDFontName', while processing a CIDFont with TrueType outlines for a PDF file, which is the same as the CIDFont BaseFont name. Since PDF can only have one descendant font per CIDFont this should not cause name collisions. To avoid interference with PostScript the key is removed from the current dictionary after use. In the TrueType interpreter, if we are handling a CIDRFont then after loading the TT tables we check to see if /PDFCIDFontName is defined. If it is we use it to replace the /FontName and /CIFontName values. This means we only ever create the font with a single name, which avoids the confusion with pdfwrite. With this change pdfwrite only emits a single font and, usefully, it has the same name as the font in the original PDF file. Expected Differences None git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9897 a1074d23-0009-0410-80fe-cf8c14f379e6
* Add bounds checking to various icclib functions.Ralph Giles2009-07-281-69/+401
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on a set of patches by Jan Lieskovsky at Red Hat, addressing CVE-2009-0583 and CVE-2009-0792. Details: Various _get_size and _write methods in icclib 2.01 were vulnerable to integer overflow from corrupt or malicious profile data. This commit makes a number of changes to address this. First, it enforces bounds checking on array indicies generated through tag data lookup or floating point calculations, either throwing an error or clamping, depending on the context. Second, it converts a number of malloc(nelement*size) calls into calloc(nelements, size), passing responsibility for overflow control to the standard library. This works on recent glibc, MacOS 10.4 (at least) and MSVC 2005 (at least; I believe MSVC 6 doesn't check for overflow). Systems which overcommit memory allocations generally also lazily zero pages, so the performance implications of an overflow in calloc() resulting in a huge allocation (or the same happening at the request of corrupt or malicious ICC profile data) are not as bad as might appear relative to the original malloc(). From the other side, multi-processing systems must often zero pages delivered to malloc anyway to prevent information leakage. On top of Jan's patches, this commit uses a fallback for SIZE_MAX, a stdint.h define which isn't available on all platforms (notably MSVC), and changes a number error message to match the malloc->calloc changes. It fixes a serious bug where the new error checking code incorrectly rejected valid profiles with an MLUT but no black point tag. icc_get_luobj() always tried to load the black point tag, and if it wasn't found, icc_read_tag() would set an error flag, which was later picked up in icmLut_read() by the check added for the results of icmLut_get_size(). Since the black point tag is optional, and icclib already substitutes a default (0,0,0) black point if none is contained in the profile, we just reset the error condition within icc_get_luobj(). vtm2k.pdf is a good testfile for this issue. Likewise, the length of lookup tables was limited to 100 points, as a resource consumption constraint, but the spec allows LUTs with up to 255 points. Bug690495.pdf from the regression suite triggered this problem. Thanks to Michael Vrhel for these last two fixes. Expected Differences: None. git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9895 a1074d23-0009-0410-80fe-cf8c14f379e6
* Update of the Esc/Page laser printer drivers from Epson and Avasys, new ↵Till Kamppeter2009-07-274-14/+151
| | | | | | output devices "eplmono" and "eplcolor", and new media types. git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9893 a1074d23-0009-0410-80fe-cf8c14f379e6
* The fill adjustment change in r9882 was too great; this rev changes it to ↵Marcos H. Woehrmann2009-07-271-1/+1
| | | | | | 0.3 (from the original 0.25). git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9892 a1074d23-0009-0410-80fe-cf8c14f379e6
* Add some debug that can be handy in tracing memory usage with the chunk manager.Ray Johnston2009-07-241-0/+22
| | | | | | This code has not effect on non-debug builds. git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9888 a1074d23-0009-0410-80fe-cf8c14f379e6
* Fix (pdfwrite) : Incorrect table in /Unicode /Decoding ResourceKen Sharp2009-07-241-49/+49
| | | | | | | | | | | | | | | | | | | | | | | | | Details Bug #690648 "many incorrectly encoded Latin Extended-A characters" The job in this issue contains a subset incrementally downloaded TrueType font where the Encoding is such that the first glyph encountered is encoded at character position 1, the second at position two and so on. In addition there is no GlyphNames2Unicode dictionary. pdfwrite tries, whenever possible, to write a ToUnicode CMap into the output PDF file which allows Acrobat and other consumers to copy and paste text using Unicode values. Since there is no Unicode information in the file, and the Encoding is distinctly non-standard, we fall all the way back to using the glyph names as a last ditch attempt to generate the Unicode information. This relies on the /Unicode /decoding resource, it seems that many glyphs in this resource were (and possibly still may be) encoded at the wrong Unicode code points. This patch fixes the glyphs raised in the bug report, there may be others. Expected Differences None. Only affects a non-marking element when producing PDF files. git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9887 a1074d23-0009-0410-80fe-cf8c14f379e6
* Temporarily address bug #690646 with a fatter fill adjustment default.Henry Stiles2009-07-231-1/+1
| | | | | | | | | This will only affect tests with resolutions less than 150 dpi. The change makes superfluous code in gs_init.ps which initializes the default fill adjust to .5 iff the resolution is greater than or equal to 150 dpi. git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9882 a1074d23-0009-0410-80fe-cf8c14f379e6
* The commits provides proper transparency support for fills with patterns ↵Michael Vrhel2009-07-2211-18/+1163
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | that contain transparency. This is a merge of the pattern_trans branch into the trunk. DETAILS: When a pattern contains a transparency, it should be blended with the underlying objects according to the current extended graphic state settings (e.g. knockout, blend mode etc). Prior to this commit, patterns with transparency behaved always as knockout fills. This fixes Bug 690467 and fixes issues for files that contain transparency patterns in the regression suite when using the pbm output device. When a transparency is present in a pattern, a pdf14 device is pushed. Pattern accumulation will then occur in the transparency buffer. When the accumulation completes, the buffer that is created is no longer passed to the pattern tile object gx_pattern_trans_t through pdf14_put_image, but instead the buffer and various details about the buffer are placed in the existing planar form into a new member of gx_pattern_trans_t called ttrans. When a path is to be filled with the pattern, we will be in pdf14_fill_path. If the color to fill with is of type pattern1_color, then we will do a call to pdf14_tile_pattern_fill which pushes a transparency group the size of the path that we are filling, in the base color space of the tile. We decompose the path to a rectangle list which is then filled using gx_trans_pattern_fill_rect. If the fill is simple, i.e. if the tile step size and tile size are the same, then a straight forward non-overlapping fill of the rectangle occurs. Otherwise a more complex filling occurs where the tiles may overlap. If the tiles overlap, then blending will need to occur. Optimizations were implemented to avoid blending if it is not required. In addition, memcpy was used for the inner loop filling (rows) when dealing with the non overlapped case. Going from planar data in the tile buffer to planar data in the transparency group that we are filling is much more efficient then switching between planar to chunky and back to planar like we would have had to do if we had used pdf14_put_image and stored the tile data in the buffer that is used for the nontransparency case. Once the fill completes, the transparency group is popped, which will perform the appropriate blending with the parent group in the proper color space. Currently it is not allowed to have the transparency tile stored as a clist. Instead the tile is always stored in the ttrans object. It would probably be worthwhile to fix this at some point. When we are doing clist processing, code was added to write (gx_dc_pattern_trans_write_raster) and read (gx_dc_pattern_read_trans_buff) the ttrans object to and from the clist. DIFFERENCES EXPECTED: tests_private/comparefiles/Bug688631.pdf (pbmraw 600dpi) tests_private/comparefiles/Bug688728a.pdf (pbmraw 600dpi) tests_private/comparefiles/Bug688728b.pdf (pbmraw 600dpi) tests_private/comparefiles/Bug689422.pdf (ppmraw 600dpi) tests_private/comparefiles/Bug689422.pdf (pkmraw 600dpi) tests_private/comparefiles/Bug688728.pdf (pbmraw 600dpi) git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9880 a1074d23-0009-0410-80fe-cf8c14f379e6
| * Fix for case when underlying buffer includes shape plane, plus fix of minor ↵Michael Vrhel2009-07-173-1/+35
| | | | | | | | | | | | | | | | | | | | offset calculation bug during memcpy fills. DETAILS: When we are filling with the pattern, the underlying group may have a shape plane, which we will need to fill with 255s during our fill of the rects. This occurs when we have a knockout group for example. git-svn-id: http://svn.ghostscript.com/ghostscript/branches/pattern_trans@9870 a1074d23-0009-0410-80fe-cf8c14f379e6
| * Optimizations when filling with patterns that include transparency.Michael Vrhel2009-07-167-13/+103
| | | | | | | | | | | | | | | | DETAILS: There are two optimizations here. One is that if there is no overlap of the tiles, then we want to go ahead and tile without blending. So we now detect the case when the tiles will not overlap and if that is the case we do a filling which does not blend the overlapping tiles. The other optimization, is to use memcpy in the inner loop when we are filling with the pattern buffer for the case where there is no blending. For this we have a memcpy for the left tile portion, a number for mem copies for the full tiles and then a memcpy for the right tile portion. git-svn-id: http://svn.ghostscript.com/ghostscript/branches/pattern_trans@9865 a1074d23-0009-0410-80fe-cf8c14f379e6
| * Fix for infinite loop that was caused by failure to update the current ↵Michael Vrhel2009-07-151-0/+1
| | | | | | | | | | | | pattern cache size during the freeing of a tile that included a transparency object. git-svn-id: http://svn.ghostscript.com/ghostscript/branches/pattern_trans@9861 a1074d23-0009-0410-80fe-cf8c14f379e6
| * Merge from trunk through revision 9854.Michael Vrhel2009-07-11133-9192/+10825
| | | | | | | | git-svn-id: http://svn.ghostscript.com/ghostscript/branches/pattern_trans@9855 a1074d23-0009-0410-80fe-cf8c14f379e6
| * Addition of code for transparency group color space handling when we are ↵Michael Vrhel2009-07-104-6/+118
| | | | | | | | | | | | | | | | | | | | filling with transparent tiles and added code for blending with self overlapping pattern tiles DETAILS: Addition of code to ensure that the proper color space is used during the push of the transparency group for the pattern path fill. The base color space for the pattern is used. When the group is popped it will then be converted and blended with the parent group. Also, added code so that if the step matrix is such that the tiles overlap we will do proper transparency blending of the tiles. This code should be optimized at some point. git-svn-id: http://svn.ghostscript.com/ghostscript/branches/pattern_trans@9854 a1074d23-0009-0410-80fe-cf8c14f379e6
| * Addition of code to handle case when there is not a rectlist but just a ↵Michael Vrhel2009-07-081-0/+16
| | | | | | | | | | | | single rectangle to fill with the transparency pattern. git-svn-id: http://svn.ghostscript.com/ghostscript/branches/pattern_trans@9849 a1074d23-0009-0410-80fe-cf8c14f379e6
| * Turn off debug defines.Michael Vrhel2009-07-072-2/+2
| | | | | | | | git-svn-id: http://svn.ghostscript.com/ghostscript/branches/pattern_trans@9845 a1074d23-0009-0410-80fe-cf8c14f379e6
| * Fix for missing matrix translation from clist phase changes during tiling ↵Michael Vrhel2009-07-073-85/+47
| | | | | | | | | | | | code. Also clean up of commented code and fix for potential access violations. This is close to being finished. Need to do a bit more testing, merge in the trunk changes and do a cluster push to test. git-svn-id: http://svn.ghostscript.com/ghostscript/branches/pattern_trans@9843 a1074d23-0009-0410-80fe-cf8c14f379e6
| * Fix for access violations when transparency pattern is stored and read from ↵Michael Vrhel2009-07-052-10/+22
| | | | | | | | | | | | | | | | | | | | clist. DETAILS: When we are rendering with the clist, there is no pdf14 device that is associated with the pattern. During immediate processing a pointer to that device is contained and used for debug purposes however the pointer is NULL during the clist reading phase. git-svn-id: http://svn.ghostscript.com/ghostscript/branches/pattern_trans@9840 a1074d23-0009-0410-80fe-cf8c14f379e6
| * Addition of code to read from clist the transparency tile. Only part ↵Michael Vrhel2009-07-041-4/+90
| | | | | | | | | | | | remaining should be to add pdf14 compositor actions into the clist to push and pop a transparency group around the fill. git-svn-id: http://svn.ghostscript.com/ghostscript/branches/pattern_trans@9838 a1074d23-0009-0410-80fe-cf8c14f379e6
| * Addition of code to write pattern transparency data into clist.Michael Vrhel2009-07-033-4/+174
| | | | | | | | git-svn-id: http://svn.ghostscript.com/ghostscript/branches/pattern_trans@9835 a1074d23-0009-0410-80fe-cf8c14f379e6
| * Removal of temporary debug code and implementation of non-simple tile case ↵Michael Vrhel2009-07-023-79/+19
| | | | | | | | | | | | (e.g. tile with 30 degree rotated step matrix). Need to implement case where tile is a clist and need to do a bit more testing. git-svn-id: http://svn.ghostscript.com/ghostscript/branches/pattern_trans@9831 a1074d23-0009-0410-80fe-cf8c14f379e6
| * With this commit we are getting proper output for the simple tiling case. ↵Michael Vrhel2009-07-021-14/+15
| | | | | | | | | | | | Next need to work on the more complex case and also look at the case where the tile is a clist device. git-svn-id: http://svn.ghostscript.com/ghostscript/branches/pattern_trans@9830 a1074d23-0009-0410-80fe-cf8c14f379e6
| * Fix to make sure we push an isolated transparency group and also get the ↵Michael Vrhel2009-06-304-11/+342
| | | | | | | | | | | | | | | | | | proper pointer to the buffer. Start of code to perform tiled filling. DETAILS: This has bunch of debug items in it that will go away as I move forward. The tiling options will be split into a few different cases. One is for simple tiling, which is where the step matrix is the same size as the tile and there are no cross terms in the step matrix. That is the easy case and will be straight forward to implement. When the tiling is skewed things become a bit more complex. I am hoping to leverage the existing code for the non-transparency tiling case but it is poorly commented. Also, things will be a bit complicated due to the fact for each pixel ALL overlapping tiles should be blended within that pixel. Obviously there is no blending in the current code. Also, need to add in the case for when the tile is a clist. Basically there is much to do here. git-svn-id: http://svn.ghostscript.com/ghostscript/branches/pattern_trans@9827 a1074d23-0009-0410-80fe-cf8c14f379e6
| * Addition of code to obtain rect list for intersection of path and clip path, ↵Michael Vrhel2009-06-238-4/+175
| | | | | | | | | | | | push of proper sized transparency group, loop for going through rect list and pop of transparency group to force blending. git-svn-id: http://svn.ghostscript.com/ghostscript/branches/pattern_trans@9818 a1074d23-0009-0410-80fe-cf8c14f379e6
| * Free transparency structure when pattern device is closed.Michael Vrhel2009-05-291-0/+6
| | | | | | | | git-svn-id: http://svn.ghostscript.com/ghostscript/branches/pattern_trans@9771 a1074d23-0009-0410-80fe-cf8c14f379e6
| * Change to no longer install memory device to hold pattern buffer if the ↵Michael Vrhel2009-05-281-24/+54
| | | | | | | | | | | | pattern has transparency. Instead we will use the buffer that was created by the pdf14 device during the pattern accumulation. git-svn-id: http://svn.ghostscript.com/ghostscript/branches/pattern_trans@9768 a1074d23-0009-0410-80fe-cf8c14f379e6
| * After pattern paint finishes, get the buffer information from the pdf14 ↵Michael Vrhel2009-05-285-7/+24
| | | | | | | | | | | | device into the pattern tile. The pdf14 device is then disabled. The pdf14 device and its buffers are freed when the pattern tile is freed from the pattern cache. git-svn-id: http://svn.ghostscript.com/ghostscript/branches/pattern_trans@9767 a1074d23-0009-0410-80fe-cf8c14f379e6
| * Addition of function in pdf14 device to initialize the pattern ctile ↵Michael Vrhel2009-05-283-2/+46
| | | | | | | | | | | | transparency object. This will be performed instead of the pdf14 put image operation. git-svn-id: http://svn.ghostscript.com/ghostscript/branches/pattern_trans@9766 a1074d23-0009-0410-80fe-cf8c14f379e6
| * Addition of structure to contain the transparency pattern in the ctile object.Michael Vrhel2009-05-283-5/+78
| | | | | | | | git-svn-id: http://svn.ghostscript.com/ghostscript/branches/pattern_trans@9765 a1074d23-0009-0410-80fe-cf8c14f379e6
| * Addition of raw image dump of pattern for debug purposes.Michael Vrhel2009-05-282-0/+49
| | | | | | | | git-svn-id: http://svn.ghostscript.com/ghostscript/branches/pattern_trans@9764 a1074d23-0009-0410-80fe-cf8c14f379e6
* | Enhancement (pdfwrite) : Add a new switch 'PDFACompatibilityPolicy to ↵Ken Sharp2009-07-215-2/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | control PDF/A creation when encountering invalid content. Details Bug #690500 "gs 8.63. Option dPDFA generating no pdf/a compliant files because of F key." In the reported issue the input PDF file contains a Link annotation with no /F (Flags) key defined. PDF/A states that only annotations with the 'Print' bit of the Flags field are permitted. pdfwrite was emitting the annotation, thus creating an invalid PDF/A file. The new switch PDFCompatibilityPolicy allows the user to select the behaviour for these kinds of events. The value defaults to 0, where the behaviour matches Acrobat, the file is created, but is not PDF/A compliant, a warning to this effect is given. When set to 1, the content will be omitted, resulting in a compliant PDF/A file, a warning is given for each piece of omitted content. Values other than 0 or 1 are treated as 0 and a warning is given that the value is not understood. Currently only implemented for annotations, it is expected this will be extended over time. Expected Differences None. git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9876 a1074d23-0009-0410-80fe-cf8c14f379e6
* | Add output buffer alignment code to one of the image handling branchesAlex Cherepanov2009-07-211-1/+1
| | | | | | | | | | | | | | | | | | | | where it was omitted. Fix a SEGV on Sparc platform that cannot access misaligned data. Bug 690613. DIFFERENCES: None. git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9873 a1074d23-0009-0410-80fe-cf8c14f379e6
* | Unobfuscate image scaling code: remove dead code, expand macros and typedefs.Alex Cherepanov2009-07-201-104/+89
| | | | | | | | | | | | | | | | | | All changes are algorithmically equivalent. DIFFERENCES: None. git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9872 a1074d23-0009-0410-80fe-cf8c14f379e6
* | Fix a typo in compile time flag that prevented GNU libiconv to emulateAlex Cherepanov2009-07-191-1/+1
| | | | | | | | | | | | | | | | | | | | system libiconv and caused link errors on the systems that use GNU headers but system libraries. Bug 690123. DIFFERENCES: None. git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9871 a1074d23-0009-0410-80fe-cf8c14f379e6
* | Initialize bit accumulator in LZW encoder to clear a Purify warning aboutAlex Cherepanov2009-07-171-0/+1
| | | | | | | | | | | | | | | | | | | | using an uninitialised value in an expression. The value itself is unimportant because all bits that may affect the result are shifted out. DIFFERENCES: None. git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9867 a1074d23-0009-0410-80fe-cf8c14f379e6
* | Fix processiong of numeric entry in /W2 array. Bug 690635.Alex Cherepanov2009-07-171-1/+1
| | | | | | | | | | | | | | DIFFERENCES: None. git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9866 a1074d23-0009-0410-80fe-cf8c14f379e6
* | Fix (pdfwrite): Crash with font errors.Ken Sharp2009-07-151-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Details: bug #690505: "Regression: More issues with pdfwrite and various nightly regression files" The font 'encode_char' method can return a 0 error code, but set the returned glyph name to 'gs_no_glyph' to indicate that a glyph could nto be found in a valid font. pdfwrite was then trying to get the glyph information for the 'gs_no_glyph' glyph, which caused a crash in dict_index. Fixed by detecting the gs_no_glyph and returning an error. Expected Differences None git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9862 a1074d23-0009-0410-80fe-cf8c14f379e6
* | Switch the order of an assignment and condition to fix (harmless) reading ofAlex Cherepanov2009-07-141-2/+2
| | | | | | | | | | | | | | | | | | uninitialized memory. Clear a Purify warning. DIFFERENCES: None. git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9859 a1074d23-0009-0410-80fe-cf8c14f379e6
* | Add a couple of utilities for extracting Fonts and ICC Profiles from aRay Johnston2009-07-132-0/+212
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PDF. I had these laying around and the need for these comes up from time to time. See the top of each PostScript file for usage. DETAILS: It is the responsibility of creators of PDF's to not embed fonts that are identified as not to be embedded. Ghostscript (as of rev 8603) respects the TrueType FSType FontInfo. The copyright and license of fonts and ICC profiles in a PDF will still be in force. Any knowledgeable user can use Ghostscript (or many other tools) to extract this information. We provide this utility mostly to provide the 'source' for GPL'ed fonts as required by fonts. Fonts are programs and distribution requires distribution of 'source', so this lets users get the source and (using a font editor) modify the font. See bug 690533 (if you must). git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9858 a1074d23-0009-0410-80fe-cf8c14f379e6
* | Change the GPL Ghostscript license to GPLv2 or later, instead of GPLv2-only.Ralph Giles2009-07-111-2/+3
| | | | | | | | git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9856 a1074d23-0009-0410-80fe-cf8c14f379e6
* | Don't take empty string for an answer when searching 'name' table in TrueTypeAlex Cherepanov2009-07-091-1/+1
| | | | | | | | | | | | | | | | | | | | font because some MS fonts have empty strings for platform IDs MS doesn't use. Bug 690611, customer 0. DIFFERENCES: None. git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9853 a1074d23-0009-0410-80fe-cf8c14f379e6
View Lorry Controller Status