For clarification I think the best would be to call EmbedSubsetFonts in
Write and WriteUpdate functions with PdfOutputDevice as parameter so it
will fix all other variants.
On Tue, Nov 13, 2018 at 11:51 PM Michal Sudolsky <sudols...@gmail.com>
wrote:
> Ok seems I found the problem.
>
> This is working ok on latest podofo, podofo 0.9.6, and probably for older
> versions (seems encoding is not important to make it work):
>
> PdfMemDocument doc;
> PdfPainter painter;
> painter.SetPage(doc.CreatePage(PdfRect(0, 0, 500, 800)));
> painter.SetFont(doc.CreateFontSubset("Arial", false, false));
> painter.DrawText(50, 750, "Abc");
> painter.FinishPage();
>
> doc.Write("a.pdf");
>
>
> But this not:
>
> PdfMemDocument doc;
> PdfPainter painter;
> painter.SetPage(doc.CreatePage(PdfRect(0, 0, 500, 800)));
> painter.SetFont(doc.CreateFontSubset("Arial", false, false));
> painter.DrawText(50, 750, "Abc");
> painter.FinishPage();
>
> PdfOutputDevice out("a.pdf");
> doc.Write(&out);
>
>
> Also it will not work when using "doc.Write(L"a.pdf");" on windows, or
> WriteUpdate with PdfOutputDevice because these functions are not calling
> EmbedSubsetFonts.
>
> So there are 2 functions which call EmbedSubsetFonts:
>
> void PdfMemDocument::Write( const char* pszFilename )
> void PdfMemDocument::WriteUpdate( const char* pszFilename )
>
> And 4 functions which do not call EmbedSubsetFonts:
>
> void PdfMemDocument::Write( const wchar_t* pszFilename )
> void PdfMemDocument::Write( PdfOutputDevice* pDevice )
> void PdfMemDocument::WriteUpdate( const wchar_t* pszFilename )
> void PdfMemDocument::WriteUpdate( PdfOutputDevice* pDevice, bool bTruncate
> )
>
> Actually all functions with string argument call PdfOutputDevice
> counterparts.
>
> There is description of EmbedSubsetFonts, I would suppose it applies for
> all Write functions:
>
> /** Embeds all pending subset fonts, is automatically done on Write().
> * Just call explicitly in case the PdfDocument is needed as
> PdfXObject.
> *
> */
> void EmbedSubsetFonts();
>
> Is there reason that EmbedSubsetFonts is not called for wchar_t and
> PdfOutputDevice versions?
>
> I suppose there is some good reason they are not embedded immediately as
> non-subset fonts.
>
>
> Further when using doc.CreateFont with
> PdfFontCache::eFontCreationFlags_Type1Subsetting it is not working even
> when calling EmbedSubsetFonts before Write because it adds them into
> m_vecFonts instead of m_vecFontSubsets where is function EmbedSubsetFonts
> looking so they are never embedded. (I tried to change m_vecFonts to
> m_vecFontSubsets here but without success, seems some more things are
> needed.)
>
>
> Also if you are sending generated pdf files over network would not be
> better to write them directly into memory and circumvent slow filesystem?
> PdfOutputDevice makes this possible (if you are not using it already and
> calling EmbedSubsetFonts manually).
>
>
>
> Hi,
>> give it a try, it is supposed to fix it. And yes, font subsetting does
>> work for me (I'm using the svn trunk though, not the 0.9.6 release).
>> You can get a snapshot of the development version with:
>
>
> On Tue, Nov 13, 2018 at 9:55 PM Olivier Mascia <o...@integral.be> wrote:
>
>> > Le 13 nov. 2018 à 18:46, Michal Sudolsky <sudols...@gmail.com> a écrit
>> :
>> >
>> > Whether I use this:
>> >
>> > PdfDocument::CreateFontSubset("Arial", false, false);
>> >
>> > Or this:
>> >
>> > PdfDocument::CreateFont("Arial", false, false, false,
>> PdfEncodingFactory::GlobalWinAnsiEncodingInstance(),
>> PdfFontCache::eFontCreationFlags_Type1Subsetting);
>> >
>> > It produces invalid pdf. Acrobat says "The font 'AAAAAA+ArialMT'
>> contains bad /Widths." and indeed it does not have widths:
>> >
>> > 19 0
>> obj<</Type/Font/BaseFont/AAAAAA+ArialMT/Encoding/WinAnsiEncoding/FontDescriptor
>> 20 0 R/Subtype/TrueType>>
>>
>> For what it's worth (as a user of PoDoFo 0.9.5) I use the following code
>> to embed Consolas:
>>
>> PdfDocument::CreateFontSubset("Consolas", false, false, false,
>> PdfEncodingFactory::GlobalIdentityEncodingInstance());
>>
>> And for Arial which is ubiquitous, I simply do not embed it, quite
>> successfully with :
>>
>> PdfDocument::CreateFont("Arial", false, false, false,
>>
>> PdfEncodingFactory::GlobalWinAnsiEncodingInstance(),
>>
>> PdfFontCache::eFontCreationFlags_AutoSelectBase14,
>> false /* Don't embed */);
>>
>> I must say and admit my use case is somewhat specific because those PDFs
>> are built by some process, transmitted over the network to another one,
>> which will display them or print them. The whole production of PDF is used
>> as an intermediate medium between one remote non interactive part of the
>> software and a GUI part running on other systems, which contains display
>> and printing capabilities. So that the remote non interactive part can
>> build printed reports, even to be physically printed the next second by the
>> GUI component, in full abstraction of any knowledge of the printer or
>> display devices (except the page format).
>>
>> I don't exactly remember, why I had to choose
>> GlobalIdentityEncodingInstance() for CreateFontSubset.
>>
>> --
>> Best Regards, Meilleures salutations, Met vriendelijke groeten,
>> Olivier Mascia
>>
>>
>>
>>
>>
>> _______________________________________________
>> Podofo-users mailing list
>> Podofo-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/podofo-users
>>
>
_______________________________________________
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
