summaryrefslogtreecommitdiff
path: root/source/gprf
diff options
context:
space:
mode:
authorRobin Watts <robin.watts@artifex.com>2016-08-09 11:23:28 +0100
committerRobin Watts <robin.watts@artifex.com>2016-09-13 17:38:20 +0100
commit6446ad77363517a1adcccf0cb5167610f3ddd117 (patch)
tree78a1c96c56b40f6a5dd1d4d2769f4f02ec448a4c /source/gprf
parentbf8e4dea8d41e67ea502efb9bc9fcbf3400a0da5 (diff)
downloadmupdf-6446ad77363517a1adcccf0cb5167610f3ddd117.tar.xz
Bug 696984: Type 3 fonts bbox fixes.
The upshot of debugging this is that: 1) We can't trust the FontBBox. Certainly it appears that no one else trusts it. 2) We can't trust the d1 values in all cases, as it can lead to use rendering glyphs far larger than we'd want to. So we have the compromise used here. 1) We never clip to the FontBBox. 2) If the FontBBox is invalid, then we calculate the bbox from the contents of the data streams. 3) If the FontBBox is valid, and the d1 rectangle given does not fit inside it, then we calculate the bbox from the contents of the data streams. This could theoretically produce problems with glyphs that have much more content than they actually need, and rely on the d1 rect to clip it down to sanity. If the FontBBox is invalid in such fonts, we will go wrong. It's not clear to me that this will actually work in Acrobat/ Foxit/gs etc either, so we defer handling this better until we actually have an example. Tested with bug 694952, and bug 695843 which were the last 2 in this area.
Diffstat (limited to 'source/gprf')
0 files changed, 0 insertions, 0 deletions