Hi, Thank you, I just committed your “enc" patch (#1684).
Your subsetting patch looks very promising, but I have a few issues with it. For example, in the current HEAD, the following code works fine (I open an existing PDF and write some text on its pages with the Arial font). If I apply the patch and run the same test, the result is a corrupted PDF file (according to Adobe Reader: Invalid font data). encoding = PoDoFo::PdfEncodingFactory::GlobalWinAnsiEncodingInstance(); pdfFont = pdf->CreateFontSubset(fontName, isBold, isItalic, false, encoding, fontPath); Do you think you could look into this? Thank you. -- Palmer Zent On October 4, 2015 at 8:25:12 AM, Nenad Novak (nenad.no...@gmail.com) wrote: 2.10.2015. u 19:18, zyx je napisao/la: > I skipped that and run `make` which results in a build failure: True, now patches should be OK. I have played again (on trunk) with recent (more/or less) changes to PdfEncodings and PdfIdentityEncoding which have made broken generation of a new PDF files which are using this encoding. [r1679] <http://sourceforge.net/p/podofo/code/1679/> (78.9 kB) by pzent Moved /ToUnicode processing to PdfEncoding so it applies to all encodings by default Attempt at fixing some char/string width calculations in PdfFontMetrics PdfIdentityEncoding is useless in case when you create a new PDF's. It's working only when you edit existing PDF because in that case this encoding is fully loaded from PdfObject. Same might apply to the PdfCMapEncoding too. Here is constuctor for this encoding: PdfIdentityEncoding::PdfIdentityEncoding( int nFirstChar = 0, int nLastChar = 0xffff, bool bAutoDelete = true, PdfObject* pToUnicode = NULL ); For a new PDF, pToUnicode object does not exits, and later ConvertToUnicode and ConvertToEncoding calls will fail or return empty object as PdfEncoding member m_bToUnicodeIsLoaded is false, and m_toUnicode map is empty too. If it's safe to take assumption, that m_bToUnicodeIsLoaded is true when encoding is loaded from existing PDF, then for a new PDFs ConvertToEncoding function has to go directly to the font related PdfFontMetrics object. Anyhow PdfEncoding::ConvertToEncoding function first tries to get CID from already loaded CMap (if such object exists). If there is no match found, then second try is to get this mappings from PdfFontMetrics->GetGlyphId(lUnicode). I believe, that it should be safe to promote m_toUncode map to protected member and change conditions from: if (m_bToUnicodeIsLoaded) ... to if(!m_toUnicode.empty()) ... In the case that PDF is generated from scratch, then ConvertToEncoding has to use font metrics, to get a glyph code from a font. PdfString class already has an way to provide ConvertToUnicode translation. Here are attached encoding, subset and helloworld-base14 patches. After applying enc.patch and helloworld-base14.patch, resulting PDF should be around 248 kB, and after subset.patch, size should drop to 54 kB. Regards, ------------------------------------------------------------------------------ _______________________________________________ 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
