summaryrefslogtreecommitdiff
path: root/base/fapi_ft.c
Commit message (Collapse)AuthorAgeFilesLines
* Update postal address in file headersChris Liddell2023-04-041-3/+3
|
* Fix memory leak with PCL and fonts.Chris Liddell2022-11-291-0/+2
| | | | | Did not realise that, whilst opening a stream allocates the stream object, closing the stream does not free the stream object. So explicitly free it.
* oss-fuzz 49859: fapi/ft - don't free font data unless we own itChris Liddell2022-08-081-1/+2
| | | | Another case of this.
* FAPI - Don't free memory on error if it doesn't belong to FAPIKen Sharp2022-07-121-1/+2
| | | | | | | | | | | | | | | | | | | OSS-fuzz #44994 with this configuration: -K1048576 -r200x200 -sBandListStorage=memory -dMaxBitmap=0 -dBufferSpace=450k -dMediaPosition=1 -dcupsColorSpace=1 -dSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -sOutputFile=/temp/out.tif -sDEVICE=tiff24nc and SHA e69805c35afa4544ab4598f173c802349d86be6d caused a seg fault when freeing the font's sfnt.data in pdfi_free_font_truetype(). This is because the memory had already been freed. The memory was freed in gs_fapi_ft_get_scaled_font() due to an error calling new_inc_int() at line 1315. The error would free 'own_font_data' which was retrieved from the font at line 1281, and returned memory which was allocated by the pdfi interpreter, not by FAPI. The code round line 1282 sets 'data_owned' to false, and other places which detect errors do not free the memory if data_owned is false so this looks like a simple oversight.
* oss-fuzz 48745: Don't free font data unless FAPI owns it.Chris Liddell2022-07-051-1/+2
|
* Change how pdfi interacts with FAPI for Truetype fontsChris Liddell2022-07-041-19/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In PDF, only symbolic Truetype fonts draw marks from the glyph at GID zero (the TTF notdef). But the default TTF notdef is an empty rectangle, rather than the Postscript style non-marking glyph. The FAPI/Freetype incremental interface integration includes code to spot that case, and return an empty glyph. Since PDFs don't do incremental font definitions, the pdfi code simply passed the TTF into FAPI, and onto Freetype as a complete font, so all the glyph lookups were handled inside Freetype, not using the incremental interface. Thus we lost the ability to do that "filtering". Equally, we don't want to take the time to break down the font and "reassemble" it as the Postscript interpreter is forced to do. This implements a hybrid approach where we still pass the font data unchanged into Freetype, but we still use the incremental interface, allowing that notdef filtering to happen. This commit affects a heuristic in freetype which autmatically enables autohinting, meaning we'll no longer get autohinting in cases where we previously did. That gives a perceived drop in quality at low resolutions. Since autohinting can be enabled at the command line, it's not a serious concern.
* Have freetype properly reset the FT_GlyphLoader on errorChris Liddell2022-07-041-15/+0
| | | | | | | | | | | | Some of the error exit code paths in FT_GlyphLoader_CheckPoints() skipped the code that reset the FT_GlyphLoader, meaning a subsequent glyph creation would attempt to use a partially initialised FT_GlyphLoader and potentially crash. Stems from, and replaces original fix for, oss-fuzz: 44994 Change included upstream: https://gitlab.freedesktop.org/freetype/freetype/-/commit/1a242558be670626ed2ec62efb1909c000b2cae7
* oss-fuzz 47795: Check we have an FT glyph before using it.Chris Liddell2022-06-061-1/+1
| | | | | | The code assume that if we had a glyph object from FT it would be either a bitmap or outline glyph, but it can also be "non", in which case we should not try to use it.
* oss-fuzz 44994: Deal with partially initialized TTF hiting contextChris Liddell2022-02-241-0/+15
| | | | | | | | | | | | An out of memory error can leave the FT TTF hinting context in a partially initialized state. Meaning bad things can happen if we try to render another glyph using the same context. Ideally this would be handled by FT internally, but that means some implications for supporting out of spec fonts, and performance. By destroying, recreating and resetting the FT size, it invalidates the (possibly corrupt) hinting context, and ensures a fresh start in any subsequent call.
* oss-fuzz 44855: Don't ignore Freetype error codeChris Liddell2022-02-211-0/+4
| | | | | | In one of the "in extremis" fallback cases, the return code from Freetype wasn't being acted upon, leaving a partially initialised glyph bitmap, that we subsequently attempt to use, resulting in a crash.
* Don't forcibly replace glyph metrics in Freetypeghostpdl-9.56.0-test-base-5Chris Liddell2022-02-071-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, Freetype was unclear about the incremental interface's call back to retrieve glyph metrics. It implied it was a way to supply "custom" metrics. That turns out not to be the case: it is intended for the (extremely rare!) cases when the "real" glyph metrics are not available directly from the the glyph description, font tables etc. Thus using it for custom metrics caused problems for Truetype glyph hinting programs, because those metrics are used to populate the zone points which the hinting programs use. Freetype resolved things at their end, and I put a solution in place for the interface code, but it turned out to be insufficient. It was still allowing the custom advance width to be set. This caused glyph hinting issues, for example: tests_private/comparefiles/Bug691824.ps at 600dpi. And spacing issues, with many PCL tests, for example: tests_private/xl/xlats/WWEPGUJ3.BIN at 600 dpi. This prevents *any* custom metrics being supplied to Freetype in cases where it causes problems (mainly incremementally defined TTFs), and handles custom advance widths outside of Freetype.
* Only select cmap table for newly create Freetype fontsChris Liddell2021-11-021-43/+44
| | | | | | | | The code selecting the cmap table was erroneously in the common between creating a completely new Freetype font, and rescaling an existing one, which opened the chance we'd end up with a cmap selected we did not expect. Move that code into the block only for newly created Freetype fonts.
* Bug 703785: Tweaking ft over/underflow workaroundsghostpdl-9.56.0-test-base-0Chris Liddell2021-10-181-2/+2
| | | | | | | | | | | | | | There was a workaround for underflow conditions when running FAPI with pdfwrite/ps2write, which caused the glyph code to throw errors, or produce poor glyph positioning in the vector output - the workaround raised the smallest Freetype scale we'd allow by an order magnitude. However, that could cause poor rendering at smallish scaling, with certain fonts. The original pdfwrite/ps2write output issues are no longer relevant, and the errors from the glyph code are resolved by a tweak to the degenerate matrix matrix handling in the FAPI interface.
* Bug 704439: Deal better with extreme glyph scaling.Chris Liddell2021-10-181-0/+2
| | | | | | | | | | In the event that a font is scaled up to such an extent that it would overflow the 16.16 fixed point representation in FAPI, produce a glyph scaled to the resolution only (saves underflow!) and scale the points in the outline as we create the Ghostscript path later on. Also, take a harder line if we overflow Ghostscript's own fixed point coordinates.
* Check cmap table validity before selectingChris Liddell2021-06-081-1/+3
| | | | | | | | Freetype, it turns out, counts and lists cmap tables even if they are invalid and cannot be used, Thus We have to explicitly check that the table we're interested in is, in fact, valid, before using it.
* Update copyright to 2021Chris Liddell2021-03-151-1/+1
|
* Bug 694692: Handle custom left-sidebearing values.Chris Liddell2020-12-031-14/+25
| | | | | | | | | | | | | | | | | Ghostscript was ending up ignoring LSB values read from Metrics dictionaries. This stemmed from some confusion about Freetype's incremental interface API get_metrics call. We had taken the references to "overriding" the metrics to mean it allowed for custom metrics to be passed into (and back out of) Freetype. That is not the case: it is intended to allow integrations supporting "incomplete" (primarily TrueType) fonts, such as PCL/XL embedded TTFs, that are permitted to omit certain tables - specifically, in this case, the hmtx and vmtx tables. So, this drops that approach, and applies custom LSB values in our code. Coincidentally, this also makes gs somewhat immune from a pending change in Freetype related to that get_metrics call.
* Bug 702985: drop use of FT_CALLBACK_DEF() defChris Liddell2020-10-201-3/+3
| | | | | | | | | | From 2.10.3, Freetype disappeared the FT_CALLBACK_DEF() macro, which is what we used when defining our callbacks from Freetype. No guidance forthcoming from the Freetype developer who made those changes, so change to explicitly declaring the callbacks file static. Should fix the reported build failures.
* Strip trailing whitespace from .c and .h files.Robin Watts2020-09-091-4/+4
|
* Revisions to FAPI (error handling etc).Chris Liddell2020-06-171-16/+24
| | | | | | | | | | | | | | | | | | | | A lot of the FAPI methods made no account for errors (i.e. a call to return an unsigned 16 bit value would return an unsigned short int). In various places that meant we ended up using unlikely (in practice, impossible, yet still "valid") values to indicate an error condition. This commit changes those calls to have a conventional Ghostscript "int" return value and (mostly) take pointer to the storage into which they should write their value. We can now return meaninful error codes. Secondly, in several places, the FAPI methods and code used integers to store character codes, cids, gids etc. This is less than ideal because we potentially have to handle 4 byte codes (especially for gids), and we also use some special 64 bit values (when available) for specific meanings. There were several workarounds for that, in various places. This commit also changes the FAPI API and code to the gs_glyph type for all such values, removing the need for those workarounds
* Update copyright to 2020Chris Liddell2020-04-101-1/+1
|
* Add a way to record the selected cmapChris Liddell2019-08-021-0/+15
| | | | (for the pdfi branch)
* Bug 700952: re-introduce over/underflow workaroundChris Liddell2019-04-111-6/+27
| | | | | | | | | | | | | | | | | | | Commit 355434f4b1bbe8c4f98cafad5a6868aa2f0eaae1 reverted a workaround that compensated for over/underflow in Freetype's TTF hinting (related to freedom and projection vector calculations). That problem no longer exists in recent Freetype releases, and the workaround actually caused other issues to occur with hinting. What wasn't obvious was that the workaround also protected over/underflow issues relating to the unitsPerEm value. So this re-instates the workaround, but bases the decision on how the final scale is distributing between the Freetype "size" and the Freetype matrix on the unitsPerEm value (this is relevant for all font types as, for non-TTF, font types, Freetype derives the unitsPerEm from the FontMatrix (for PS type fonts). Also fixes Bug 700875
* Bug 700533: Undo FT over/underflow workaroundChris Liddell2019-02-121-19/+4
| | | | | | | | | | | | Older versions of Freetype had a problem with overflow (and underflow) in the Truetype hinting code. That was resolved some time ago with the addition of (or handling of) the F_dot_P value. In the file associaited with this issue, the glyph offset is caused by this workaround. Thus the workaround is no longer required, and as it actually causes a problem, it is hereby removed.
* Update source/header file copyright notice to 2019Chris Liddell2019-01-161-1/+1
|
* Only use FT weight vector API if FT is new enoughChris Liddell2018-11-291-0/+6
| | | | So strictly later than 2.9.1 or when using our patched sources (SHARE_FT==0)
* Use the new Freetype FT_Set/Get_MM_WightVector APIChris Liddell2018-11-281-27/+23
| | | | | | | | Being able to set the weight vector in an existing FT font object avoids the need to recreate the font every time the weightvector changes in Postscript. Creating an FT font is a time consuming operation, so this can save considerable time in jobs that make heavy use of multiple master fonts
* Work around a behaviour change in freetype > 2.8Chris Liddell2018-05-181-0/+6
| | | | | | | | | | | | | | | | Freetype will throw an error when we try to retrieve the glyph if the x/y advance values are too big to fit in a 16.16 fixed point value. Since we have no need of those values, set them to zero, and avoid the error. Bring freetype up to 2.9.1 Plus the gs makefile changes to support the new version. Reapply "Work around a change in the zlib API for 1.2.11" for Freetype commit: 08482c582115a1396d0fd9186011008f889a61c5
* Bug 698767: Improve handling of multiple master fontsChris Liddell2018-04-111-1/+40
| | | | | | | | | | | | The FAPI API didn't really handle the possibility that multiple master fonts could change (via setweightvector) without a call to definefont/setfont etc. We now allow two ways for FAPI to handle this: if the scaler in force allows it, we'll set the new weight vector, and carry on as before. If the scaler does *not* allow us to change the weight vector "on the fly", we'll destroy the scaler's font object and related data, and recreate it with the new weight vector in the font dictionary.
* Update copyright notice with new head office address.Ken Sharp2018-01-301-3/+3
| | | | | | | | | Also update copyright dates. Remove gs_cmdl.ps as we no longer use it, and remove its entry from psfiles.htm. Remove xfonts.htm as this feature (xfont support) is long, long gone.
* Bug 694260: FAPI: tidy up error return for broken TT glyphChris Liddell2018-01-261-4/+12
| | | | | | | | | | | | | | | In the event of an error retrieving a TTF glyph, we were storing the negative error code in the same variable we use to store the glyph length for a valid glyph, which is an unsigned variable, causing a valgrind error, and potential security issue reading uninitialized memory. In fact, other consumers silently cope with this type of problem and (presumably) use a notdef glyph instead. So this tweaks the error codes to do the same. Because we now have to differentiate between different types of error, we can no longer just use a negative value, so there is an enumerated type for the error values.
* Rejig gs_fapi_ft_ensure_open to avoid error cleanup SEGV.Robin Watts2017-12-021-22/+18
| | | | Also, aesthetics.
* Fix FAPI memory leaks.Chris Liddell2017-08-221-1/+12
| | | | | | | | | | | | Noticed while chasing down other memory issues. Two issues, as it turns out: Firstly, descendants of a composite font were not having the notify method set, so we can free the FAPI related memory for the font. Secondly, the Freetype incremental interface object created for each font was not freed along with the font object.
* MSVC: Fix some implicit casting warnings in ft_api.cRobin Watts2017-06-281-8/+8
| | | | Simply make the castings explicit.
* Bug 697983: (re-redux) Drop zero length contours from glyph outlinesChris Liddell2017-06-261-44/+78
| | | | | | | | | | | | | | | | Zero length contours cause issues (line-caps) when the outline is stroked. Turns out the same problem can arise with arcs as with straight lines. That complicates things where TTFs are concerned since we have to convert cubic to conic splines, and the floating point errors make it dubious checking for point equality after the conversion. As a result, the checking has to be done in the scaler specific interface code, rather than in the scaler independant FAPI code. That just means if we ever integrate another scaler that can handle downloadable fonts, we need to take care to include the same checks as are now in the Freetype interface code.
* Bug 697545: Memory Squeezing fix.Shailesh Mistry2017-02-271-0/+1
| | | | | | | Fix memory leak for allocation event number 22 when memory squeezing: gs -sDEVICE=bit -o /dev/null: examples/tiger.eps
* Update freetype to 2.7.0Chris Liddell2016-11-221-0/+3
| | | | | | Tweak makefile for new freetype version Force use of the v35 Freetype bytecode interpreter
* Further compensation for Freetype number representationChris Liddell2016-08-101-2/+21
|
* Change allocator initialization.Chris Liddell2016-04-271-3/+2
| | | | | | | cppcheck reckoned the pointer to the memory allocator (cmem) could possibly be a NULL pointer dereference (in fact, that's not true). But a simple tweak to how cmem is initialized can prevent the error arising.
* Coverity IDs 95065, 121457: tidy up error conditionsChris Liddell2016-04-251-1/+10
|
* Improve logability of errors.Robin Watts2016-02-181-9/+9
| | | | | Ensure that we always return_error(gs_error_blah) rather than just return gs_error_blah.
* Tidy up cmap table selection in fapi_ft.cChris Liddell2016-01-071-19/+22
| | | | | | | | Rearrange so we don't try to select the cmap table for non-TT fonts, and only once. Also, make it explicit and comment the fact we ignore the return value from the Freetype call.
* Bug 696232: apply metrics for PCL TTF fonts.Chris Liddell2015-10-091-0/+13
| | | | | | | Specifically, metrics for Format 1 Class 2 glyph data. Several PCL/PXL files show differences, most are not really visible without pixel level comparisons, a very few are (mostly subtle) progressions.
* Commit of build_consolidation branchChris Liddell2015-07-201-0/+1745
Squashed into one commit (see branch for details of the evolution of the branch). This brings gpcl6 and gxps into the Ghostscript build system, and a shared set of graphics library object files for all the interpreters. Also, brings the same configuration options to the pcl and xps products as we have for Ghostscript.
View Lorry Controller Status