Hi,
There are many initialised static local variables which is thread-safe only
in C++11 and above what is ok.
What is not ok is that there are two class member static variables which
are initialised lazily in some member function.
These cases are definitely not thread-safe. There should be
Hi,
Looking at code of PdfPainter destructor there is stated that throwing
exception in c++ destructors is not allowed but at bottom that
PODOFO_ASSERT is throwing exceptions. This basically means that throwing my
own exceptions between SetPage and FinishPage will results in abort because
podofo
On Sun, Dec 17, 2017 at 4:46 PM, zyx <z...@gmx.us> wrote:
> On Thu, 2017-12-07 at 18:15 +0100, Michal Sudolsky wrote:
> > Maybe that one line should be:
> >
> > > m_pNext = new PdfOutlineItem(
> > > pObj, m_pParentOutline, this );
>
In function PdfListField::GetItemDisplayText:
if( nIndex < 0 || nIndex > static_cast(opt.size()) )
> {
> PODOFO_RAISE_ERROR( ePdfError_ValueOutOfRange );
> }
> PdfVariant var = opt[nIndex];
There should be >= comparision. This function with nIndex same as opt.size()
In function PdfString::SetHexData:
// Now check for the first two bytes, to see if we got a unicode string
> if( m_buffer.GetSize() > 4 )
> {
> m_bUnicode = (m_buffer.GetBuffer()[0] == static_cast(0xFE) &&
> m_buffer.GetBuffer()[1] == static_cast(0xFF));
>
> if( m_bUnicode )
>
Not sure whether this is known bug but I think if yes then it would be
fixed long ago. When adding more than 65 entries in name tree then "Limits"
keys are wrongly set. Acrobat will not forgive that, it will not see all
names. Example code:
PdfMemDocument doc;
> for(int i = 0; i < 66; i++)
> {
Hello,
Recursion is at many places, not only in PdfParser, I have feeling
everywhere where is recursion in pdf structures like trees, for example
GetPageNode in PdfPagesTree. There is no problem to create small pdf with
too large depth, also this can be cycled via references and I am now not
sure
I created two sample pdf files. When you merge them with podofomerge in
order "first.pdf", "second.pdf" then outlines from second.pdf are not
clickable.
On Wed, Feb 21, 2018 at 9:41 PM, Michal Sudolsky <sudols...@gmail.com>
wrote:
> Yes seems this is fixed in lat
On Mon, Dec 18, 2017 at 9:20 AM, zyx <z...@gmx.us> wrote:
> On Sun, 2017-12-17 at 17:08 +0100, Michal Sudolsky wrote:
> > From code around seems it really does not depend what parent is here
> > set, I followed logic above and did it like this (this is all what I
>
nfo string "This
is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version
6.2.2".
On Mon, Dec 18, 2017 at 10:21 AM, zyx <z...@gmx.us> wrote:
> On Sun, 2017-12-17 at 17:29 +0100, Michal Sudolsky wrote:
> > I changed only this one line:
> >
> > -
Just for record. (Actually it could be also without any checks like was in
podofo 0.9.5 and rather crash with null pointer and non-zero length as in
other places in podofo.)
On Sun, Oct 28, 2018 at 3:47 PM zyx wrote:
> On 27.10.2018 at 19:46 Michal Sudolsky wrote:
> > Actually bet
al, hello zyx, hello all,
>
> > On 29 October 2018 at 16:39 Michal Sudolsky
> wrote:
> >
> >
> > I just meant there are other places where I can call function with NULL
> > buffer and non-zero length to make crash for example
> "PdfImage::LoadFromData&qu
I do not think this was good change:
https://sourceforge.net/p/podofo/code/1870/tree//podofo/trunk/src/base/PdfOutputStream.cpp?diff=50f1cef7e88f3d7cbdd252d0:1869
I would rather ignore such call to write:
if( !pBuffer )
{
return 0;
}
Because there are things in podofo which
I just meant there are other places where I can call function with NULL
buffer and non-zero length to make crash for example
"PdfImage::LoadFromData".
On Mon, Oct 29, 2018 at 8:36 AM zyx wrote:
> On Sun, 2018-10-28 at 19:28 +0100, Michal Sudolsky wrote:
> > crash with null p
Base 14 fonts have hardcoded underline and strikeout thickness set to zero.
On enlarged texts this looks really bad. I am sending how it looks in
attachment when using Helvetica and when using some freetype font.
In PdfFontMetricsObject.cpp is almost something sane:
// Try to fine some
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
ubsetting 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 wrote:
> > Le 13 nov. 2018 à 18:46, Michal Sudolsky a écrit :
> >
> > Whether I u
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
wrote:
> Ok seems I found the problem.
>
> This is working ok
ee it in 0.9.7. Value 0.05
> looks well but perfect value would be little higher (at least to match
> Helvetica in Acrobat).
>
> On Tue, Nov 13, 2018 at 8:43 PM zyx wrote:
>
>> On Tue, 2018-11-13 at 17:36 +0100, Michal Sudolsky wrote:
>> > Base 14 fonts have hardcoded
100, Michal Sudolsky wrote:
> > This is really unfortunate because pdf with just subset of font could
> > be much smaller when I want to add just short text into it (or can be
> > smaller also with long text because how often can be found pdf which
> > contains all ch
is good idea to have PODOFO_BUILTIN_FONTS const and
PODOFO_Base14FontDef_FindBuiltinData to return const pointer.
On Fri, Nov 16, 2018 at 5:56 PM Michal Sudolsky wrote:
> Fonts created for different documents should be independent. In other case
> you cannot do anything usable with the
Which shared data do you mean? Also I forgot that fonts with same name are
shared in document so you cannot have two "Arial" font objects with
different sizes, so yes you are right.
On Fri, Nov 16, 2018 at 7:49 PM Francesco Pretto wrote:
> On Fri, 16 Nov 2018 at 19:34, Michal Su
orkaround of the real issue: PdfFont
> is stateful and it should not be. I would recommend you to use the fix
> for your local copy of PoDoFo, but mainstream should have better
> solution, at the cost of breaking the API and of course it's a much
> more invasive change.
>
>
>
>
> > Ah ok, I got it. Yes, std::vector usage is definitely better choice.
>
> No, it's not. Why to add an overhead of the std::vector class on
> something what is a string, a plain character array? Just add
> podofo_free() on appropriate places and fix the other things and that's
> it.
>
Hi,
By the way when making podofo 0.9.6 on osx there are these 2 warnings:
podofo-0.9.6/src/base/PdfParser.cpp:899:31: warning: format specifies type
'long *' but the argument has type 'PoDoFo::pdf_int64 *'
(aka 'long long *') [-Wformat]
, , , ,
);
>
>
> the size of that member PdfVariant::m_eDataType was reduced to
> 8 bits to save RAM space because PdfVariant objects are abundant
> when using PoDoFo, not so much with the other ones you mention.
> Therefore I don't agree with your proposal. The commit of my
> change has made svn r1959 [1],
>
>
> AFAIK, "None" and "Unknown" are different (e.g. for filters "None" means
> it's known that no filter is applied whereas "Unknown" means it isn't
> known which filter is applied (or the filter applied is unsupported in
> PoDoFo, at least in the used revision). Therefore, where "None" makes
>
You can use -D_LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR with gcc and maybe
other compilers have something similar.
But the best would be to replace auto_ptr with unique_ptr in podofo (and
move to git, ...).
On Wed, Dec 5, 2018 at 10:44 PM Olivier Mascia wrote:
> Dear all,
>
> Just an outsider
When calling function "PdfFont* PdfMemDocument::GetFont( PdfObject* pObject
)" to get existing font from pdf it marks some objects like font object and
"widths" as dirty so in updating mode are overwritten even when there is no
change. What is worse it breaks font using difference encoding by
2-03 at 23:06 +0100, Michal Sudolsky wrote:
> > The best is to initialise it during creation of
> > PdfDifferenceEncoding. And only place which creates
> > PdfDifferenceEncoding is "PdfFont* PdfMemDocument::GetFont(
> > PdfObject* pObject )".
>
> Hi,
>
```
PdfMemDocument doc;
PdfPainter painter;
painter.SetPage(doc.CreatePage(PdfRect(0, 0, 500, 800)));
painter.SetFont(doc.CreateFont("Helvetica"));
painter.DrawText(0, 780, "Text 1");
PdfWin1250Encoding();
painter.SetFont(doc.CreateFont("Helvetica", false, false, false,
Function PdfEncodingDifference::ContainsUnicodeValue already gets its
unicodeValue parameter as big endian but it then treats it like machine
endian and swaps bytes then compares this against unicodeValues in
m_vecDifferences which are stored as big endian.
Proposed patch attached.
When using font created by function with signature "PdfFont*
PdfMemDocument::GetFont( PdfObject* pObject )" for drawing text then are
not rendered characters outside of base encoding if specified font uses
difference encoding for these characters for example if font was created by
using
unimplemented as this would require
converting glyph to cid for cid encoding.
On Wed, Nov 28, 2018 at 11:39 PM Michal Sudolsky
wrote:
> PdfFontMetricsObject::UnicodeCharWidth returns width for CID instead of
> unicode char (like does PdfFontMetricsFreetype and PdfFontMetricsBase14).
> May
Patch with corrected indentation attached.
On Wed, Dec 5, 2018 at 8:31 PM Michal Sudolsky wrote:
> Proposed patch attached.
>
> It follows something similar what is doing ConvertToEncoding in its core.
> Now widths of all font supported unicode chars are correctly obtain
There is this:
PdfOutputDevice::PdfOutputDevice( const std::ostream* pOutStream )
But this will not set m_pReadStream so signing pdf opened/created using c++
streams is not possible. Because signing requires to read file after it is
written.
On the other hand when opening from const char*
PdfFontMetricsObject::UnicodeCharWidth returns width for CID instead of
unicode char (like does PdfFontMetricsFreetype and PdfFontMetricsBase14).
Maybe it can be fixed by converting unicode char into CID using
m_pEncoding->GetCIDValue (after few modifications). And implement also
Patch attached. I changes it to way as it is used in other places like
WidthExporter::update (which is seems used for font subset). In pdf
reference is stated that default width (DW key) is integer, then also
widths (W key) should be array of integers. But main purpose of this is
that object of
Discard previous diff. I hope final fix but someone should check it.
On Fri, Nov 16, 2018 at 6:17 PM Michal Sudolsky wrote:
> One thing I forgot. PODOFO_Base14FontDef_FindBuiltinData is used on places
> where return value is not deallocated. This would cause memory leaks. I am
> sendi
Also I would not recommend SHA1.
On Sun, Jan 13, 2019 at 8:58 PM Michal Sudolsky wrote:
> Hi,
>
> From attached cpp file:
>
> ```
>
> unsigned char* p7Buf = (unsigned char*) malloc(p7Len);
>
> unsigned char *p;
>
> p=p7Buf;
>
> i
Hi,
>From attached cpp file:
```
unsigned char* p7Buf = (unsigned char*) malloc(p7Len);
unsigned char *p;
p=p7Buf;
if (p7Buf != NULL) {
int len = i2d_PKCS7(p7, );
printf("%i", len);
std::cout << "p7Buf filled";
}
PKCS7_free(p7);
ISE_ERROR( ePdfError_ValueOutOfRange );
}
On Tue, Mar 26, 2019 at 8:49 PM Michal Sudolsky wrote:
>
>>
>>
>> for (int i = 0; i < curPage->GetNumAnnots(); i++)
>>
>> {
>>
>> curAnno = curPage-&
Hi,
I sent more which are still pending. At least let me know if some are not
acceptable so I can remove it from pending things ;)
On Thu, Feb 21, 2019 at 5:38 PM Matthew Brincke wrote:
> Hello Michal, hello all,
>
> > On 29 November 2018 at 17:26 Michal Sudolsky
> wrote:
&
Hi,
No, This is really not good idea. Probably many pdf which are working now
with podofo will stop working. First pdf which I checked now has SPACE+LF
and it opens fine in any possible pdf viewer. Also OpenOffice generates
SPACE+LF (version 4.1.2 on windows probably).
Also in pdf reference is
Maybe better would be to check whether are both empty1 and empty2
whitespaces.
On Wed, Mar 6, 2019 at 9:48 AM Michal Sudolsky wrote:
> Hi,
>
> No, This is really not good idea. Probably many pdf which are working now
> with podofo will stop working. First pdf which I checked now
>
>
> When trying to load the used pdfs there, nearly all of them produced some
> loading errors (which is fine, I guess). But four of them could be loaded,
> so I could check them against my own signature validation code. Sadly, my
> code did not find any signature fields for two of the four
Hi,
I have feeling that this will not work for characters encoded as values
bigger than 8-bits (if this is possible in difference encoding, I need to
refresh memory about it). Did you test "č" or "Č"?
On Thu, Feb 21, 2019 at 10:53 PM BLANCHARD Christophe <
christophe.blanch...@3ds.com> wrote:
>
>
> On the contrary I think podofo is too strict. Maybe would be better that
>> it actually can open these files with xref entries shorter or longer than
>> 20 chars as readers from that page do. I think some readers are implemented
>> to read xref table by lines (by using for example c++
There are indeed 3 checkboxes in one group and 3 radio buttons in another
group. Either podofopdfinfo info is wrongly reading acroforms or bug is in
podofo depending on point of view (I have feeling that code for acroforms
was written 10 years ago and no change was made since then). Acroform
lines of duplicated code is still
> duplicated code and lead to this kind of issues), is there any reason
> we shouldn't just push the attached change to fix the wrong
> subsetting/embedding of fonts?
>
> Cheers,
> Francesco
>
>
> On Tue, 13 Nov 2018 at 23:52, Michal Sudolsky
If you are sure that you have some radio buttons then check what is
returning curField.GetType(). I am sure that GetType() will
return correctly ePdfField_RadioButton for radio buttons as I am using it
but I never tried IsRadioButton() function.
On Mon, Mar 18, 2019 at 1:30 AM
Hi,
Probably because they are indeed checkboxes. Seems there is missing
implementation of PdfRadioButton there is only this "// TODO: Dominiks
PdfRadioButton". To add radion button you need to add PdfButton and call
"SetFieldFlag(ePdfButton_Radio, true);". Radio buttons are grouped by using
same
le totally out
>> of place). With this, Podofo can load the files and my code finds the
>> signature and checks it to valid. So I've got to agree with you, the xref
>> entry size is not needed for the attack. If the researchers had paid
>> attention to it, the pdf files
Hi,
Can you provide some details? PDF and or code snippet causing this. Did you
use base 14 font (Helvetica, Courier, Times-Roman) with identity encoding?
On Wed, Feb 13, 2019 at 4:24 PM Hiremath, Santhosh Boloshankar <
santhosh.hirem...@siemens.com> wrote:
> Hi,
>
>
>
> Environment used for
On Thu, Jan 24, 2019 at 12:14 PM zyx wrote:
> On Wed, 2019-01-23 at 20:09 +0100, Michal Sudolsky wrote:
> > I am tempted to note that -1 is stored in 8-bit integer in exactly
> > same way as 0xFF.
>
> Hi,
> I used the code below with gcc 8.1.1 with this result
>
>
> > +if ( it == names.end() )
>
> Bonus points if you make the names.end() called only once, not two-
> times-the-length-of-the-array in the cycle, but it's not a question for
> this change. It's for other places in the code, to do some performance
> improvements.
> Bye,
>
r your response,
> though.
>
> On Thu, Jun 20, 2019 at 12:08 PM Michal Sudolsky
> wrote:
>
>> Hi,
>>
>> If I am not wrong such properties are stored in NTFS filesystem
>> "metadata". It has nothing to do with PDF file itself. These properti
Hi,
If I am not wrong such properties are stored in NTFS filesystem "metadata".
It has nothing to do with PDF file itself. These properties are not PDF
properties. Yes podofo is unnecessary for this.
On Thu, Jun 20, 2019 at 11:31 AM wrote:
>
> Hi! I’d like to implement a Windows property
Hi,
Yes difference is that GetReference() must be called on object which is of
type ePdfDataType_Reference and that object is casted to PdfReference.
Reference() can be called on indirect object and it returns PdfReference
which "points" to it.
This is indirect object which is dictionary,
Function PdfContentsTokenizer::ReadInlineImgData in
PdfContentsTokenizer.cpp:
```
c = m_device.Device()->GetChar();
if (c=='E' && m_device.Device()->Look()=='I')
{
// Consume character
m_device.Device()->GetChar();
int w =
If function png_read_image encounters error it will call longjmp and will
jump to place where was called setjmp. In such case pBuffer and pRows will
never be deallocated.
Cut of code from mentioned functions:
```
// Read the file
if( setjmp(png_jmpbuf(pPng)) )
{
>
> Until this patch the code was buildable with ancient compilers, which
> do not support vector::data().
I am sending modified patch. I do not see any reason why would be better to
use preprocessor to switch between "[0]" and "data.data()". The first
form should do same thing on C++11 as on
I am getting PdfError at "PdfString str1( ar.c_str() );":
PoDoFo encountered an error. Error: 8 ePdfError_InternalLogic
Error Description: An internal error occurred.
Callstack:
#0 Error Source: podofo/base/PdfString.cpp:171
My guess is that in order to join these characters you would need to do
If is podofo exception thrown between "new" and "delete" then this memory
will be leaked. Lines 638-663:
```
char *buffer = new char[bufferSize];
if( !buffer )
{
TIFFClose(hInTiffHandle);
PODOFO_RAISE_ERROR( ePdfError_OutOfMemory );
}
for(row = 0; row < height;
Hi,
You did not send enough details. I can only guess what font name you used
and how you draw string but when I tested your text it shows in pdf without
spaces. Btw base14 fonts cannot be used with identity encoding.
On Fri, Dec 6, 2019 at 1:29 PM Igor Mironchik
wrote:
> Hello.
>
> I try to
/*
> * We have to check if an error has occurred.
> * If yes, we return and print an error message
> * to the commandline.
> */
> eCode.PrintErrorMsg();
> return eCode.GetError();
> }
>
>
> try {
> /*
if this is working well in podofo 0.9.6:
PdfDocument::CreateFontSubset
On Fri, Dec 6, 2019 at 3:55 PM Michal Sudolsky wrote:
> Hi,
>
> Can you try with latest podofo?
> https://sourceforge.net/p/podofo/code/HEAD/tree/
>
> On Fri, Dec 6, 2019 at 3:52 PM Igor Mironchik
when is specified identity encoding.
On Fri, Dec 6, 2019 at 4:23 PM Igor Mironchik
wrote:
> Hi,
> On 06.12.2019 17:55, Michal Sudolsky wrote:
>
> Hi,
>
> Can you try with latest podofo?
> https://sourceforge.net/p/podofo/code/HEAD/tree/
>
>
> In the trunk rev 1999 th
I am just user of podofo and had similar problems as you.
On Fri, Dec 6, 2019 at 4:35 PM Igor Mironchik
wrote:
>
> On 06.12.2019 18:29, Michal Sudolsky wrote:
>
> Hi,
>
> As you can see there are much more problems with 0.9.6. You are better
> with latest podof
Hi,
Maybe you can try PdfMemDocument.
https://sourceforge.net/p/podofo/mailman/message/36792946/
On Tue, Dec 10, 2019 at 8:22 PM Igor Mironchik
wrote:
> Hello,
>
> I need to draw some additional stuff on pages that were processed before
> and PdfPainter::FinishPage() was called.
>
> I do:
>
reated font is: 25.968750
Width of 'ČŘĎ' using loaded font is: 0.00
```
Without patch in this email chain.
On Wed, Dec 5, 2018 at 8:34 PM Michal Sudolsky wrote:
> Patch with corrected indentation attached.
>
> On Wed, Dec 5, 2018 at 8:31 PM Michal Sudolsky
> wrote:
>
>
Hi,
How it looks with this bug?
On Sat, Jun 1, 2019 at 9:22 PM Michal Sudolsky wrote:
> I am sending test case:
>
> ```
>
> PdfMemDocument doc;
> PdfPage *page = doc.CreatePage({0, 0, 500, 800});
> PdfFont *font = doc.CreateFont("Verdana", false, fal
>
>
> 1. I would need to know the horizontal displacement of a glyph and I am
> using GetGlyphWidth(), if that is correct what about the vertical
> displacement?
>
If I am not wrong fonts in pdf have defined only widths. But I guess height
could be in font file or can be calculated from glyph
>
>
> Eventually, it could be a global (static) property of the PdfParser, to
> make things even simpler. Would there be a need to use PdfParser from
> multiple threads with different setting at the same time? I guess not.
> This would make the patch much smaller.
>
> Ideas?
>
I think better
Hi,
There are places which expects only direct objects but these objects may be
also indirect. As is stated in
https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf at
the end of section 7.3.10 "indirect objects" - any object value may be
direct or indirect reference except
>
>
> tabs are harder to spot. What I noticed, by reading, is an extra space
> after 'if' in:
>
> +if ( s_bIgnoreBrokenObjects )
>
> As I said, that's a really minor thing.
>
>
I just ignored this one because it was here also before and the author just
changed "m" to "s".
I contribute to
t;
> Is there any way to write the generated glyphs as text in PDF document
> using PoDoFo library?
>
>
>
> Regards,
>
> Anand.
>
> *From:* Anand Ramasamy
> *Sent:* Thursday, February 13, 2020 9:26 PM
> *To:* Michal Sudolsky
> *Cc:* podofo-users@lists.sourceforge.ne
>
>
> Hi,
> just to make things clearer, I also do not like global variables as
> such. What I've been thinking of was to provide something similar to
> PdfError::EnableLogging() and PdfError::EnableDebug(). That would work
> fine, no?
> Bye,
> zyx
>
>
There is little
d to check
whether is returned value reference in contrast with faster operator[] of
PdfArray (although also this operator checks for "mutability").
On Thu, Mar 5, 2020 at 9:04 PM Michal Sudolsky wrote:
> Hi,
>
> Seems there is only one merge conflict due to r1990 which I think c
Hi,
Seems there is only one merge conflict due to r1990 which I think could be
fixed in better way by using new "FindAt" function or similar (I would
propose to add "MustFindAt" which would check that it does not return NULL
and also whether is index within array bounds).
On Wed, Feb 26, 2020 at
>
> (to make
> it easier to merge your giant change, to deal with as less conflicts as
> possible).
>
It would be easier with git. Also probably more people would collaborate as
it is easier system than sending patches via email where merge conflicts
are up to you.
>
> Are you still willing to
Hi,
There are places where is used GetIndirectKey but the intention was clearly
to use MustGetIndirectKey because returned value is
immediately dereferenced. Also it is better that in case of invalid pdf is
rather thrown exception from MustGetIndirectKey than to crash due to
accessing invalid
>
>
> (and one really minor coding style "violence").
>
>
Do you mean that one added tab?
> I didn't try to build this yet, but I do not expect any problem with
> it. I'll commit this (updated) after Francesco changes land.
> Thanks again and bye,
> zyx
>
>
>
>
in
pdf (I did not research this much).
On Thu, Feb 27, 2020 at 5:18 PM Michal Sudolsky wrote:
> Hi,
>
> This podofo thread may be useful:
> https://sourceforge.net/p/podofo/mailman/message/32419281/
>
> So suppose font was added to pdf either by podofo api or manually as
> desc
you and Michal were suggesting, but if I've
> misunderstood please let me know!
> --
> JS
>
> -Original Message-
> From: zyx
> Sent: Thursday, February 27, 2020 1:55 AM
> To: podofo-users
> Cc: John Senneker
> Subject: Re: [Podofo-users] [External] Re: Patc
Seems well. Maybe also m_bStrictParsing could be static. Seems there is no
way how to turn on strict parsing (if anyone need this at all).
On Thu, Feb 27, 2020 at 8:20 PM John Senneker
wrote:
> Good catch. Here’s the patch with that code added back.
>
>
>
> *From:* Michal Su
Hi,
There are also other "load" functions like LoadFromBuffer and
LoadFromDevice. Why are these not covered?
On Thu, Feb 13, 2020 at 6:08 PM John Senneker
wrote:
> Hello,
>
> The patch I sent you had a merge mistake, which caused the new
> bIgnoreBrokenObjects parameter not to be passed to the
I am sending updated patch which covers also these two functions.
On Mon, Feb 17, 2020 at 11:41 PM Michal Sudolsky
wrote:
> Hi,
>
> There are also other "load" functions like LoadFromBuffer and
> LoadFromDevice. Why are these not covered?
>
> On Thu, Feb 13, 2
> Good catch! There’s no reason in principle why the flag shouldn’t be added
> to the other Load functions as well. I didn’t add them there because I
> don’t use those functions, and I’m not sure whether or not the flag makes
> sense there. Your patch looks good to me, but because I don’t use thos
Hi,
In PdfParser.cpp in function PdfParser::ReadObjectsInternal():
pObject->ParseFile( m_pEncrypt );
*if* (m_pEncrypt && pObject->IsDictionary()) {
PdfObject* pObjType = pObject->GetDictionary().GetKey( PdfName::KeyType );
*if*( pObjType && pObjType->IsName() && pObjType->GetName() == "XRef"
using some
class member method.
On Thu, Feb 20, 2020 at 8:27 AM zyx wrote:
> On Wed, 2020-02-19 at 16:57 +0100, Michal Sudolsky wrote:
> > I think ignoring broken objects should be the default behaviour
>
> Hi,
> I can second that, it makes perfect sense.
>
&g
21, 2020 at 7:45 PM Michal Sudolsky wrote:
> Hi,
>
> I do not think that this patch is bad. It fixes problems and can be
> amended also later to ignore broken objects by default so there is no
> reason to not apply it in its current form. Except that someone does not
> like new
ut rather
referenced object. There are much less places which really wants references
like copying/sharing resources without duplications.
On Tue, Feb 18, 2020 at 7:06 PM Michal Sudolsky wrote:
> In this part of patch PdfVecObjects::GetObject may return NULL into
> pFontObject (in case of in
Hi,
There were added two "FIXME" comments like this:
- if( rhs.m_pStream && m_pOwner )
- m_pStream = m_pOwner->CreateStream( *(rhs.m_pStream) );
+ // FIXME:
+ // Copying stream is currently broken:
+ // 1) PdfVecObjects::CreateStream( const PdfStream & ) is broken as it
just returns NULL
+ // 2)
Hi,
- Evaluate deprecation of PdfObject::GetIndirectKey() as same
> functionality is now provided directly inside PdfDictionary in
> a more consistent API.
I think GetIndirectKey is still useful as GetDictionary will throw if
object is not dictionary and better is to ignore possibly incorrect
It should be same as Identity-H. There are also other encodings defined in
pdf reference which are not supported by podofo.
Looking at this code it looks that podofo is treating encoding which it
does not support as internal logic error rather than user error which
suggests it is actually error
Hi,
There is this part of code in PdfObjectStreamParserObject.cpp:
*if*( m_pEncrypt && (m_pEncrypt->GetEncryptAlgorithm() == PdfEncrypt::
ePdfEncryptAlgorithm_AESV2
#ifndef PODOFO_HAVE_OPENSSL_NO_RC4
|| m_pEncrypt->GetEncryptAlgorithm() == PdfEncrypt::
ePdfEncryptAlgorithm_RC4V2
#endif //
Hi,
Seems currently the only option how to open pdf encrypted with password is
to try-catch around "Load" function and in case of specific exception call
"SetPassword" to finalise loading. But as name suggests exceptions should
be used for exceptional things which do not occur very often also
mitted and resolved.
On Fri, Mar 27, 2020 at 6:07 PM zyx wrote:
> On Mon, 2020-03-02 at 21:32 +0100, Michal Sudolsky wrote:
> > Patch attached.
>
> Hi,
> thanks for the patch, I committed it as r2002:
> http://sourceforge.net/p/podofo/code/2002
>
>
>
> Hi,
> okay, that sounds correct. I'm not sure whether your mail is complete,
> it seems to be cut for some reason.
>
> Having there a way to know whether password is needed is required, no
> doubt. I would not drop the current call-flow though, as many library
> users rely on it.
>
1 - 100 of 181 matches
Mail list logo
