Hi Nenad,
Thanks, that was it. I committed your patch as r1694.
Sorry it took so long.
--
Palmer Zent
On October 27, 2015 at 3:49:41 PM, Nenad Novak (nenad.no...@gmail.com) wrote:
Hi Palmer,
I believe that I know what is the main cause of problem.
Do not call Init() when font is loaded from PDF. I have removed the comment,
and
that bites me.
PdfFontCID::PdfFontCID( PdfFontMetrics* pMetrics, const PdfEncoding* const
pEncoding, PdfObject* pObject, bool )
: PdfFont( pMetrics, pEncoding, pObject ), m_pDescendantFonts( NULL )
{
/* this->Init( bEmbed, false ); No changes to dictionary */
m_bWasEmbedded = true; /* embedding on this path is not allowed at all, so
pretend like it's already done */
}
Anyhow, if you try to reuse font subset and draw glyphs which are not included
there, then missing glyphs should get a .notdef representation.
Whenever you open existing PDF document, PdfFontMetrics is constructed from
PdfFontMetricsObject. This is totally different creation path from that one
used
when you create a new PDF and use CreateFont.
For a new PdfDocument font creation goes from FontCache through the
PdfFontFactory::CreateFontObject, but FontMetrics is already a concrete class,
instantiated in PdfFontCache class and for Freetype fonts it uses a
PdfFontMetricsFreetype implementation.
Whenever you open existing PDF, PdfFont and related PdfFontMetrics classes are
constructed from objects found in dictionary. Path is
PdfFontFactory::CreateFont. In that case only a synthetic PdfFontMetricObject
is
constructed. If the font is embedded (or embedded as subset) and uses a
Freetype
font behind, there is no attempt to create PdfFontMetricsFreetype class from
"FontFile2" object (what should be possible).
This is a reason why Svetlana can't get GetGlyphId (other thread), because
PdfFontMetricsObject can't get this information and returns 0. BTW, Svetlana
does not know that 'Tj' and 'TJ' operators are already using GlyphId's, and she
needs only to convert this glyphs to unicode
(PdfEncoding::GetCharCode(glyphid)).
Now, I see that PdfFontCID is also constructed from that second path, and for
shore it does in Init() some probably undesired changes to dictionary with
bogus
PdfFontMetrics object. In that case no changes are allowed at all, and that was
a reason why initially Init() was not called at all, until I have uncommented
that line.
Regards,
Nenad
26.10.2015. u 1:38, Palmer Zent wrote:
> I ran a few tests and it does seem to work as you said. Unfortunately, there
> is still a regression when you add text to an existing PDF file. The freshly
> added text is displayed correctly but it looks like all the already embedded
> fonts become corrupted. Acrobat shows garbage instead of the text and it
> complains that it cannot find the fonts. The same code works fine without the
>
> patch. Any idea what could cause this?
>
------------------------------------------------------------------------------
_______________________________________________
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
