On 27.3.2020 v 19:09 Francesco Pretto wrote:
I'm sorry I couldn't end up merging the patch myself after giving
> availability at first but I am actually happy you found the time to
> better review it since it's very core modification.
Hi,
that's okay. My review was nothing comprehensive
Thank you very much zyx! Unfortunately it happened that in this period
I am even more busy because of the COVID19 emergency: I'm sorry I
couldn't end up merging the patch myself after giving availability at
first but I am actually happy you found the time to better review it
since it's very core mo
On Thu, 2020-03-05 at 21:04 +0100, Michal Sudolsky wrote:
> 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 whe
Also I personally think "FintAt" should also check index and return NULL if
it is higher or equal to array size. In that way it would be easier to use
it on many places and will be more akin to FindKey. Regarding performance
impact this should be negligible because there it still need to check
whet
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
On Mon, 2020-02-24 at 20:51 +0100, Francesco Pretto wrote:
> I will not be able to fix the conflicts, re-test and commit the patch
> myself for at least 2 weeks.
Hi,
that's okay, there is no hurry. I won't get to it sooner too. Unless
you beat me I'll give it a try in around the similar ti
On Sun, 23 Feb 2020 at 11:06, zyx wrote:
>
> On Fri, 2020-02-21 at 19:27 +0100, Michal Sudolsky wrote:
> > Why is automatic object ownership still not merged into master? When
> > it will be?
>
> Hi Francesco,
> I'm not sure you received my last email in this thread, I sent it only
> to th
>
> (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 m
On Fri, 2020-02-21 at 19:27 +0100, Michal Sudolsky wrote:
> Why is automatic object ownership still not merged into master? When
> it will be?
Hi Francesco,
I'm not sure you received my last email in this thread, I sent it only
to the list. I gave you a confirmation to commit your changes
Also for some places might be useful to have member function in PdfObject
which will dereference it in case of reference. Something like this:
PdfObject *PdfObject::Deref()
{
*if*( !IsReference() ) *return* *this*;
*if*( !m_pOwner )
{
PODOFO_RAISE_ERROR_INFO( ePdfError_InvalidHandle, "Object
Hi,
Why is automatic object ownership still not merged into master? When it
will be?
That thing which I mentioned was here in similar form also before:
*if* (descendant.size() && descendant[0].IsReference())
{
pFontObject = pObject->GetOwner()->GetObject( descendant
The comment absolutely states pre-existing bugs and no regressions are
introduced. I know it also because I fixed that exact issue in a
unsent patch.
On Tue, 18 Feb 2020 at 17:59, Michal Sudolsky wrote:
>
> Hi,
>
> There were added two "FIXME" comments like this:
>
> - if( rhs.m_pStream && m_pO
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 pd
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)
On Mon, 2019-11-04 at 08:53 +0100, zyx wrote:
> I can give it some smoke testing in my environment, both with
> internal PoDoFo test suite and from the litePDF side (just one
> project, which builds on top of the PoDoFo), but I cannot promise
> when it'll be. It can take a long time.
Hi,
I
On Mon, 2019-10-28 at 23:22 +0100, Francesco Pretto wrote:
> I kindly ask some of you to review this work as I consider it
> important for the future of PoDoFo.
Hi,
I'm sorry to admit this, but I'm afraid I cannot help much here. I can
give it some smoke testing in my environment, both wit
Dear Dominik, Matthew, Zyx, and all PoDoFo develpers,
I kindly ask some of you to review this work as I consider it
important for the future of PoDoFo. It has been extensively tested for
almost one year with important number of automatic test cases (100+)
by very different users. High quality stan
17 matches
Mail list logo