Issue 7128058: [PDF] Detect and handle font mismatches triggered by .skp files.

Keyboard Shortcuts

	File
u :	up to issue
m :	publish + mail comments
M :	edit review message
j / k :	jump to file after / before current file
J / K :	jump to next file with a comment after / before current file
	Side-by-side diff
i :	toggle intra-line diffs
e :	expand all comments
c :	collapse all comments
s :	toggle showing all comments
n / p :	next / previous diff chunk or comment
N / P :	next / previous comment
<Up> / <Down> :	next / previous line
<Enter> :	respond to / edit current comment
d :	mark current comment as done

	Issue
u :	up to list of issues
m :	publish + mail comments
j / k :	jump to patch after / before current patch
o / <Enter> :	open current patch in side-by-side view
i :	open current patch in unified diff view

	Issue List
j / k :	jump to issue after / before current issue
o / <Enter> :	open current issue
# :	close issue

	Comment/message editing
<Ctrl> + s or <Ctrl> + Enter :	save comment
<Esc> :	cancel edit

Issue 7128058: [PDF] Detect and handle font mismatches triggered by .skp files. (Closed)

Can't Edit
Can't Publish+Mail
Start Review

Created:
12 years, 5 months ago by Steve VanDeBogart

Modified:
12 years, 5 months ago

Reviewers:
edisonn, bungeman, reed1

CC:
skia-review_googlegroups.com

Base URL:
https://skia.googlecode.com/svn/trunk

Visibility:
Public.

More Reviews

Description

[PDF] Detect and handle font mismatches triggered by .skp files.

Patch Set 1 #

Created: 12 years, 5 months ago

Download [raw] [tar.bz2]

		Unified diffs	Side-by-side diffs	Delta from patch set	Stats (+12 lines, -2 lines)			Patch
	M	src/pdf/SkPDFFont.cpp	View		1 chunk	+12 lines, -2 lines	0 comments	Download

Messages

Total messages: 4

Expand All Messages | Collapse All Messages

bungeman

On 2013/01/18 23:20:14, Steve VanDeBogart wrote: NAK, this isn't a good fix for https://codereview.appspot.com/7127056/ . ...

12 years, 5 months ago (2013-01-22 14:37:18 UTC) #2

reed1

Does this only get triggered when we're using SKPs, or is it possible for the ...

12 years, 5 months ago (2013-01-22 15:08:46 UTC) #3

Steve VanDeBogart

12 years, 5 months ago (2013-01-22 18:50:47 UTC) #4

This should only happen with SKP playback.

The code path I've modified in this CL is only hit when we've successfully drawn
text, but the max glyph id of the font has gotten smaller when we try to
actually emit the PDF.  i.e. it requires the font file to change between drawing
and and writing the pdf out.  As far as I know, this is only possible with SKP
playback.

The print out is there to be helpful - we don't have to have it, or can make it
debug only.  As is, it will happen once per font per PDF output.

On 2013/01/22 15:08:46, reed1 wrote:
> Does this only get triggered when we're using SKPs, or is it possible for the
> caller to generate this just by drawing into a PDF device? Does the printf
need
> to be .skp specific?
> 
> How often will that printf appear? Once per draw? Once per bad glyph? Does it
> need to be in release code, or just debug code?

On 2013/01/22 14:37:18, bungeman wrote:
> NAK, this isn't a good fix for https://codereview.appspot.com/7127056/ . We
need
> to make sure we don't crash in general when drawXXXText is called with glyph
> encoding and some or all of the glyphs are not in the font. While this was
> exposed by pdfs and skps, neither pdf nor pictures are the place to try to
> handle this.

I agree that we shouldn't crash if we draw a glyph id above font.num_glyphs, but
that's not what this change is about.

Expand All Messages | Collapse All Messages