When we read from a RemoteFontStream (might happen maybe with other streams), stream's data might b…

src/pdf/SkPDFFont.cpp

Index: src/pdf/SkPDFFont.cpp
===================================================================
--- src/pdf/SkPDFFont.cpp	(revision 8280)
+++ src/pdf/SkPDFFont.cpp	(working copy)
@@ -549,6 +549,7 @@
                                   SkPDFStream** fontStream) {
     int ttcIndex;
     SkAutoTUnref<SkStream> fontData(typeface->openStream(&ttcIndex));

[vandebo (ex-Chrome), 2013/03/21 00:55:11]

Shouldn't typeface->openStream() return a stream at the beginning?

[bungeman-skia, 2013/03/21 03:25:12]

I have to agree, this is an issue with reed's changes to
SkFontHost_fontconfig.cpp::open_stream. We shouldn't try to band-aid this here
and leave this to still happen elsewhere.

It looks like on Windows and Mac we always create a new stream on OpenStream.
With the fontconfig font host, it looks like we're often just ref-ing and
returning. This seems iffy, the old code made a copy, maybe this is why? It
seems what we want there is a shallow stream copy.

[edisonn, 2013/03/21 13:33:08]

done; added issue 1176 for the thread safety. right now we will fix simply by
rewinding in open_stream

On 2013/03/21 03:25:12, bungeman1 wrote:

+    fontData->rewind();

[edisonn, 2013/03/21 13:33:08]

Steve's comments:
1) openStream should give already a stream at the beginning, I agree
2) multithreading ... multiple readers would interfere reading the data! I
suggested a lock, but Steve thinks that we need independent seek pointers, but
this might require a new interface for all SkStream classes

 
     int fontSize = fontData->getLength();