PDFedit

On Fri, Oct 09, 2009 at 04:20:41PM +0200, Michal Hocko wrote:
> Hi,
> attached you can find a fix for bt#338. I wouldn't post it normally,
> because it is changes code solely in xrefwriter.cc, but I am not sure
> about its correctness wrt. PDF specification. I would be grateful to have
> another pair of eyes on that. 
> 
> The affected part of the specification is: Chapter 3, "Compatibility with PDF 1.4"
> and hybrid document files and our multiversion documents handling.

Anybody willing to go through the specification and check whether this
patch conforms?
If there is nobody to do so I think it doesn't make any sence to wait
longer and I will commit the patch. We can revert it later if it proves
being wrong.

> 
> Let me know if you have any questions.
> 
> Thanks
> -- 
> Michal Hocko

> kernel: handle hybrid-xref files correctly in XRefWriter
> 
> Fixes bt#338
> 
> PDF 1.5 and above versions of specification support so called hybrid files
> which contain both old-style xref table and xref stream. Such a document
> then looks as follows:
> 
> [@OFFSET2]
> xref
> [Standard xref entries. Hidden objects are marked as free with max gen
> number]
> trailer
> <<
> /Root [...]
> >>
> 
> [@OFFEST3]
> 1 0 obj
> <<
> /Length [...]
> >>
> stream
> [object stream data]
> endstream
> 
> [@OFFSET1]
> xref
> 0 0
> trailer
> <<
> /Prev OFFSET2
> /XRefStm OFFSET3
> >>
> 
> startxref
> OFFSET1
> %EOF
> 
> This means that this kind of file looks like a 2 revisions document. This
> wouldn't be a big problem but we have a different problem if we consider 
> this to be 2 revisions document. XRefWriter::getRevision size calculates
> revision size which is done as revStart-endPrev (where endPrev is the end
> of the previous revision), but we are not able to calculate end of the
> previous revision because xref (at OFFSET2) is not followed by startxref
> keyword as expected. Application then ends with assertion failure
> revStar>endPrev.
> 
> Of course we could fix the XRefWriter::getRevisionEnd but the point is that
> we shouldn't consider this layout multi-version in the first place. The
> "proper" fix is not considering additional xref for hybrid files at all.
> This is done in XRefWriter::collectRevisions by checking XRefStm entry in
> the trailer. 
> 
> If a hybrid document is multiversion then the referenced trailer (OFFSET2)
> should contain /Prev entry IMO. The PDF specification is not clear in this
> regard.
> 
> Index: pdfedit-patches/src/kernel/xrefwriter.cc
> ===================================================================
> --- pdfedit-patches.orig/src/kernel/xrefwriter.cc	2009-10-09 15:12:37.000000000 +0200
> +++ pdfedit-patches/src/kernel/xrefwriter.cc	2009-10-09 15:37:53.000000000 +0200
> @@ -728,23 +728,50 @@ void XRefWriter::collectRevisions()
>  		return;
>  	}
>  
> +	bool hybrid_xref = false;
>  	do
>  	{
> -		// process current trailer (store offset and get previous
> -		// if present) - we are starting with the newest one cloned
> -		// above
> -		kernelPrintDbg(DBG_DBG, "XRef offset for "<<
> -				revisions.size()<<" revision is "<<off);
> -		revisions.insert(revisions.begin(), off);
> +		// Take care about hybrid files which makes situation little bit more 
> +		// complex, because these documents usually contain 2 sections to 
> +		// describe one revision. The last (most recent one) has xref with no
> +		// entries and trailer has /Prev pointing to the xref table and XRefStm
> +		// pointing to the xref stream (PDFReference16.pdf: Chapter 3, 
> +		// Compatibility with PDF 1.4). The pervious contains referred xrefs.
> +		// This, however, doesn't mean that the document has 2 revisions so
> +		// don't add them in such a case.
> +		if (!hybrid_xref)
> +		{
> +			// process current trailer (store offset and get previous
> +			// if present) - we are starting with the newest one cloned
> +			// above
> +			kernelPrintDbg(DBG_DBG, "XRef offset for "<<
> +					revisions.size()<<" revision is "<<off);
> +
> +			revisions.insert(revisions.begin(), off);
> +		}
>  		off = getPrevFromTrailer(trailer);
>  		if(isERR_OFFSET(off))
>  			// no more previous trailers
>  			break;
> +		
> +		hybrid_xref = false;
> +		Object stm;
> +		trailer->dictLookupNF("XRefStm", &stm);
> +		if (stm.isInt())
> +		{
> +			kernelPrintDbg(DBG_INFO, "Document contains hybrid-file XREF.");
> +			hybrid_xref = true;
> +		}else if (!stm.isNull())
> +		{
> +			kernelPrintDbg(DBG_WARN, "Unexpected value for XRefStm trailer entry with type "
> +					<< stm.getType());
> +		}
> +		stm.free();
>  
>  		// checks whether given offset is already in revisions, which 
>  		// would mean corrupted referencies (because of cycle in 
>  		// trailers)
> -		if(std::find(revisions.begin(), revisions.end(), 
> +		if(!hybrid_xref && std::find(revisions.begin(), revisions.end(), 
>  					(size_t)off) != revisions.end())
>  		{
>  			kernelPrintDbg(DBG_ERR, "Trailer Prev points to already"
> @@ -755,7 +782,9 @@ void XRefWriter::collectRevisions()
>  
>  		// off is the first byte of a cross reference section. 
>  		// It can be either xref key word or beginning of the 
> -		// xref stream object
> +		// xref stream object - we have to process it even for
> +		// hybrid_xref case becase this can contain reference to
> +		// the previous revision
>  		str->setPos(off);
>  		Object parseObj; 
>  		boost::shared_ptr< ::Object> obj(XPdfObjectFactory::getInstance(), xpdf::object_deleter());

> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference

> _______________________________________________
> Pdfedit-devel mailing list
> Pdfedit-devel@...
> https://lists.sourceforge.net/lists/listinfo/pdfedit-devel


-- 
Michal Hocko

please, commit




> Date: Thu, 22 Oct 2009 15:43:22 +0200
> From: mstsxfx@...
> To: pdfedit-devel@...
> Subject: Re: [PATCH] kernel: handle hybrid-xref files correctly in XRefWriter
> 
> On Fri, Oct 09, 2009 at 04:20:41PM +0200, Michal Hocko wrote:
> > Hi,
> > attached you can find a fix for bt#338. I wouldn't post it normally,
> > because it is changes code solely in xrefwriter.cc, but I am not sure
> > about its correctness wrt. PDF specification. I would be grateful to have
> > another pair of eyes on that. 
> > 
> > The affected part of the specification is: Chapter 3, "Compatibility with PDF 1.4"
> > and hybrid document files and our multiversion documents handling.
> 
> Anybody willing to go through the specification and check whether this
> patch conforms?
> If there is nobody to do so I think it doesn't make any sence to wait
> longer and I will commit the patch. We can revert it later if it proves
> being wrong.
> 
> > 
> > Let me know if you have any questions.
> > 
> > Thanks
> > -- 
> > Michal Hocko
> 
> > kernel: handle hybrid-xref files correctly in XRefWriter
> > 
> > Fixes bt#338
> > 
> > PDF 1.5 and above versions of specification support so called hybrid files
> > which contain both old-style xref table and xref stream. Such a document
> > then looks as follows:
> > 
> > [@OFFSET2]
> > xref
> > [Standard xref entries. Hidden objects are marked as free with max gen
> > number]
> > trailer
> > <<
> > /Root [...]
> > >>
> > 
> > [@OFFEST3]
> > 1 0 obj
> > <<
> > /Length [...]
> > >>
> > stream
> > [object stream data]
> > endstream
> > 
> > [@OFFSET1]
> > xref
> > 0 0
> > trailer
> > <<
> > /Prev OFFSET2
> > /XRefStm OFFSET3
> > >>
> > 
> > startxref
> > OFFSET1
> > %EOF
> > 
> > This means that this kind of file looks like a 2 revisions document. This
> > wouldn't be a big problem but we have a different problem if we consider 
> > this to be 2 revisions document. XRefWriter::getRevision size calculates
> > revision size which is done as revStart-endPrev (where endPrev is the end
> > of the previous revision), but we are not able to calculate end of the
> > previous revision because xref (at OFFSET2) is not followed by startxref
> > keyword as expected. Application then ends with assertion failure
> > revStar>endPrev.
> > 
> > Of course we could fix the XRefWriter::getRevisionEnd but the point is that
> > we shouldn't consider this layout multi-version in the first place. The
> > "proper" fix is not considering additional xref for hybrid files at all.
> > This is done in XRefWriter::collectRevisions by checking XRefStm entry in
> > the trailer. 
> > 
> > If a hybrid document is multiversion then the referenced trailer (OFFSET2)
> > should contain /Prev entry IMO. The PDF specification is not clear in this
> > regard.
> > 
> > Index: pdfedit-patches/src/kernel/xrefwriter.cc
> > ===================================================================
> > --- pdfedit-patches.orig/src/kernel/xrefwriter.cc	2009-10-09 15:12:37.000000000 +0200
> > +++ pdfedit-patches/src/kernel/xrefwriter.cc	2009-10-09 15:37:53.000000000 +0200
> > @@ -728,23 +728,50 @@ void XRefWriter::collectRevisions()
> >  		return;
> >  	}
> >  
> > +	bool hybrid_xref = false;
> >  	do
> >  	{
> > -		// process current trailer (store offset and get previous
> > -		// if present) - we are starting with the newest one cloned
> > -		// above
> > -		kernelPrintDbg(DBG_DBG, "XRef offset for "<<
> > -				revisions.size()<<" revision is "<<off);
> > -		revisions.insert(revisions.begin(), off);
> > +		// Take care about hybrid files which makes situation little bit more 
> > +		// complex, because these documents usually contain 2 sections to 
> > +		// describe one revision. The last (most recent one) has xref with no
> > +		// entries and trailer has /Prev pointing to the xref table and XRefStm
> > +		// pointing to the xref stream (PDFReference16.pdf: Chapter 3, 
> > +		// Compatibility with PDF 1.4). The pervious contains referred xrefs.
> > +		// This, however, doesn't mean that the document has 2 revisions so
> > +		// don't add them in such a case.
> > +		if (!hybrid_xref)
> > +		{
> > +			// process current trailer (store offset and get previous
> > +			// if present) - we are starting with the newest one cloned
> > +			// above
> > +			kernelPrintDbg(DBG_DBG, "XRef offset for "<<
> > +					revisions.size()<<" revision is "<<off);
> > +
> > +			revisions.insert(revisions.begin(), off);
> > +		}
> >  		off = getPrevFromTrailer(trailer);
> >  		if(isERR_OFFSET(off))
> >  			// no more previous trailers
> >  			break;
> > +		
> > +		hybrid_xref = false;
> > +		Object stm;
> > +		trailer->dictLookupNF("XRefStm", &stm);
> > +		if (stm.isInt())
> > +		{
> > +			kernelPrintDbg(DBG_INFO, "Document contains hybrid-file XREF.");
> > +			hybrid_xref = true;
> > +		}else if (!stm.isNull())
> > +		{
> > +			kernelPrintDbg(DBG_WARN, "Unexpected value for XRefStm trailer entry with type "
> > +					<< stm.getType());
> > +		}
> > +		stm.free();
> >  
> >  		// checks whether given offset is already in revisions, which 
> >  		// would mean corrupted referencies (because of cycle in 
> >  		// trailers)
> > -		if(std::find(revisions.begin(), revisions.end(), 
> > +		if(!hybrid_xref && std::find(revisions.begin(), revisions.end(), 
> >  					(size_t)off) != revisions.end())
> >  		{
> >  			kernelPrintDbg(DBG_ERR, "Trailer Prev points to already"
> > @@ -755,7 +782,9 @@ void XRefWriter::collectRevisions()
> >  
> >  		// off is the first byte of a cross reference section. 
> >  		// It can be either xref key word or beginning of the 
> > -		// xref stream object
> > +		// xref stream object - we have to process it even for
> > +		// hybrid_xref case becase this can contain reference to
> > +		// the previous revision
> >  		str->setPos(off);
> >  		Object parseObj; 
> >  		boost::shared_ptr< ::Object> obj(XPdfObjectFactory::getInstance(), xpdf::object_deleter());
> 
> > ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay 
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> 
> > _______________________________________________
> > Pdfedit-devel mailing list
> > Pdfedit-devel@...
> > https://lists.sourceforge.net/lists/listinfo/pdfedit-devel
> 
> 
> -- 
> Michal Hocko
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Pdfedit-devel mailing list
> Pdfedit-devel@...
> https://lists.sourceforge.net/lists/listinfo/pdfedit-devel
 		 	   		  
_________________________________________________________________
Windows 7: It helps you do more. Explore Windows 7.
http://www.microsoft.com/Windows/windows-7/default.aspx?ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen3:102009

On Thu, Oct 22, 2009 at 02:36:38PM +0000, Jozef Misutka wrote:
> 
> please, commit

Ok, then. I would be much calmer if somebody did a serious review,
though.

> > On Fri, Oct 09, 2009 at 04:20:41PM +0200, Michal Hocko wrote:
> > > Hi,
> > > attached you can find a fix for bt#338. I wouldn't post it normally,
> > > because it is changes code solely in xrefwriter.cc, but I am not sure
> > > about its correctness wrt. PDF specification. I would be grateful to have
> > > another pair of eyes on that. 
> > > 
> > > The affected part of the specification is: Chapter 3, "Compatibility with PDF 1.4"
> > > and hybrid document files and our multiversion documents handling.
> > 
> > Anybody willing to go through the specification and check whether this
> > patch conforms?
> > If there is nobody to do so I think it doesn't make any sence to wait
> > longer and I will commit the patch. We can revert it later if it proves
> > being wrong.
> > 
> > > 
> > > Let me know if you have any questions.
> > > 
> > > Thanks
> > > -- 
> > > Michal Hocko
> > 
> > > kernel: handle hybrid-xref files correctly in XRefWriter
> > > 
> > > Fixes bt#338
> > > 
> > > PDF 1.5 and above versions of specification support so called hybrid files
> > > which contain both old-style xref table and xref stream. Such a document
> > > then looks as follows:
> > > 
> > > [@OFFSET2]
> > > xref
> > > [Standard xref entries. Hidden objects are marked as free with max gen
> > > number]
> > > trailer
> > > <<
> > > /Root [...]
> > > >>
> > > 
> > > [@OFFEST3]
> > > 1 0 obj
> > > <<
> > > /Length [...]
> > > >>
> > > stream
> > > [object stream data]
> > > endstream
> > > 
> > > [@OFFSET1]
> > > xref
> > > 0 0
> > > trailer
> > > <<
> > > /Prev OFFSET2
> > > /XRefStm OFFSET3
> > > >>
> > > 
> > > startxref
> > > OFFSET1
> > > %EOF
> > > 
> > > This means that this kind of file looks like a 2 revisions document. This
> > > wouldn't be a big problem but we have a different problem if we consider 
> > > this to be 2 revisions document. XRefWriter::getRevision size calculates
> > > revision size which is done as revStart-endPrev (where endPrev is the end
> > > of the previous revision), but we are not able to calculate end of the
> > > previous revision because xref (at OFFSET2) is not followed by startxref
> > > keyword as expected. Application then ends with assertion failure
> > > revStar>endPrev.
> > > 
> > > Of course we could fix the XRefWriter::getRevisionEnd but the point is that
> > > we shouldn't consider this layout multi-version in the first place. The
> > > "proper" fix is not considering additional xref for hybrid files at all.
> > > This is done in XRefWriter::collectRevisions by checking XRefStm entry in
> > > the trailer. 
> > > 
> > > If a hybrid document is multiversion then the referenced trailer (OFFSET2)
> > > should contain /Prev entry IMO. The PDF specification is not clear in this
> > > regard.
> > > 
> > > Index: pdfedit-patches/src/kernel/xrefwriter.cc
> > > ===================================================================
> > > --- pdfedit-patches.orig/src/kernel/xrefwriter.cc	2009-10-09 15:12:37.000000000 +0200
> > > +++ pdfedit-patches/src/kernel/xrefwriter.cc	2009-10-09 15:37:53.000000000 +0200
> > > @@ -728,23 +728,50 @@ void XRefWriter::collectRevisions()
> > >  		return;
> > >  	}
> > >  
> > > +	bool hybrid_xref = false;
> > >  	do
> > >  	{
> > > -		// process current trailer (store offset and get previous
> > > -		// if present) - we are starting with the newest one cloned
> > > -		// above
> > > -		kernelPrintDbg(DBG_DBG, "XRef offset for "<<
> > > -				revisions.size()<<" revision is "<<off);
> > > -		revisions.insert(revisions.begin(), off);
> > > +		// Take care about hybrid files which makes situation little bit more 
> > > +		// complex, because these documents usually contain 2 sections to 
> > > +		// describe one revision. The last (most recent one) has xref with no
> > > +		// entries and trailer has /Prev pointing to the xref table and XRefStm
> > > +		// pointing to the xref stream (PDFReference16.pdf: Chapter 3, 
> > > +		// Compatibility with PDF 1.4). The pervious contains referred xrefs.
> > > +		// This, however, doesn't mean that the document has 2 revisions so
> > > +		// don't add them in such a case.
> > > +		if (!hybrid_xref)
> > > +		{
> > > +			// process current trailer (store offset and get previous
> > > +			// if present) - we are starting with the newest one cloned
> > > +			// above
> > > +			kernelPrintDbg(DBG_DBG, "XRef offset for "<<
> > > +					revisions.size()<<" revision is "<<off);
> > > +
> > > +			revisions.insert(revisions.begin(), off);
> > > +		}
> > >  		off = getPrevFromTrailer(trailer);
> > >  		if(isERR_OFFSET(off))
> > >  			// no more previous trailers
> > >  			break;
> > > +		
> > > +		hybrid_xref = false;
> > > +		Object stm;
> > > +		trailer->dictLookupNF("XRefStm", &stm);
> > > +		if (stm.isInt())
> > > +		{
> > > +			kernelPrintDbg(DBG_INFO, "Document contains hybrid-file XREF.");
> > > +			hybrid_xref = true;
> > > +		}else if (!stm.isNull())
> > > +		{
> > > +			kernelPrintDbg(DBG_WARN, "Unexpected value for XRefStm trailer entry with type "
> > > +					<< stm.getType());
> > > +		}
> > > +		stm.free();
> > >  
> > >  		// checks whether given offset is already in revisions, which 
> > >  		// would mean corrupted referencies (because of cycle in 
> > >  		// trailers)
> > > -		if(std::find(revisions.begin(), revisions.end(), 
> > > +		if(!hybrid_xref && std::find(revisions.begin(), revisions.end(), 
> > >  					(size_t)off) != revisions.end())
> > >  		{
> > >  			kernelPrintDbg(DBG_ERR, "Trailer Prev points to already"
> > > @@ -755,7 +782,9 @@ void XRefWriter::collectRevisions()
> > >  
> > >  		// off is the first byte of a cross reference section. 
> > >  		// It can be either xref key word or beginning of the 
> > > -		// xref stream object
> > > +		// xref stream object - we have to process it even for
> > > +		// hybrid_xref case becase this can contain reference to
> > > +		// the previous revision
> > >  		str->setPos(off);
> > >  		Object parseObj; 
> > >  		boost::shared_ptr< ::Object> obj(XPdfObjectFactory::getInstance(), xpdf::object_deleter());
> > 
> > > ------------------------------------------------------------------------------
> > > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > > is the only developer event you need to attend this year. Jumpstart your
> > > developing skills, take BlackBerry mobile applications to market and stay 
> > > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > > http://p.sf.net/sfu/devconference
> > 
> > > _______________________________________________
> > > Pdfedit-devel mailing list
> > > Pdfedit-devel@...
> > > https://lists.sourceforge.net/lists/listinfo/pdfedit-devel
> > 
> > 
> > -- 
> > Michal Hocko
> > 
> > ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay 
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > Pdfedit-devel mailing list
> > Pdfedit-devel@...
> > https://lists.sourceforge.net/lists/listinfo/pdfedit-devel
>  		 	   		  
> _________________________________________________________________
> Windows 7: It helps you do more. Explore Windows 7.
> http://www.microsoft.com/Windows/windows-7/default.aspx?ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen3:102009

-- 
Michal Hocko

<COL111-W6559F31967DC50A5AF1CB0B6E80@...>

  <20090911121412.GB5727@...>

  <COL111-W540D958CC61B042CA3A972B6E60@...>

  <20090913094250.GA5913@...>

  <COL111-W4540D1DECB7083E717D01B6E50@...>

  <20090913123227.GB5913@...>

  <COL111-W170F3D5AE610DFDF5F52DDB6E50@...>

  <20090914081108.GA6204@...>
 

 <20091008120809.GB8155@...>
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0




----------------------------------------
> Date: Thu=2C 8 Oct 2009 14:08:09 +0200
> From: mstsxfx@...
> To: misutkajunior@...
> CC: martin@... pdfedit-devel@...
> Subject: Re: [RFC] tools out of pdfedit module?
>
> Any conclusion to this discussion?

i told you my expectations and sadly=2C they do not match with yours. the c=
onclusion is clear then.


>
> On Mon=2C Sep 14=2C 2009 at 10:11:08AM +0200=2C Michal Hocko wrote:
>> On Sun=2C Sep 13=2C 2009 at 06:04:16PM +0000=2C Jozef Misutka wrote:
>>>> On Sun=2C Sep 13=2C 2009 at 11:21:44AM +0000=2C Jozef Misutka wrote:
>>>>>> On Sat=2C Sep 12=2C 2009 at 02:09:04PM +0000=2C Jozef Misutka wrote:
>>>>>>>> On Thu=2C Sep 10=2C 2009 at 06:32:14PM +0000=2C Jozef Misutka wrot=
e:
>>>>>>>>>> On Thu=2C Sep 10=2C 2009 at 03:40:19PM +0000=2C Jozef Misutka wr=
ote:
>>>>>> [...]
>>>>>>>>>>>> I am thinking that=2C maybe=2C we should get tools out of the =
pdfedit source
>>>>>>>>>>>> completely and create a separate module for it in our CVS. The=
 rationale
>>>>>>>>>>>> is that we want to show how to use our pdfedit-dev-core librar=
y but it
>>>>>>>>>>>> is not used if the source is in src/tools - at least from buil=
ding POV.
>>>>>>>>>>>> If we make it a separate module we can use proper Makefile
>>>>>>>>>>>> infrastructure required for proper building and linking with t=
he
>>>>>>>>>>>> library.
>>>>>>>>>>>>
>>>>>>>>>>>> Just an idea... What do you think?
>> [...]
>>>> It looks like you are mixing two things. pdfedit-core-dev refers to th=
e
>>>> _external_ library! Something you have installed on your system and yo=
u
>>>> can easily build programs up on. Source for it is a part of PDFedit
>>>> project. There is no reason why GUI/tests should build against an
>>>
>>> It does not make sense for our unit tests to use a library externally=
=3B
>>> i hope that is clear.
>>
>> Sure=2C it is project internall stuff.
>>
>>>
>>>> external library if it is available directly.
>>>
>>> Well=2C when tools have the library available too why should they not
>>> link against it then?
>>
>> Because we want to make this an _example_ on how to use the library.
>>>From my POV this means 2 things: proper code usage and proper Makefile
>> to build the code.
>>
>>>
>>> See below.
>>>
>>>>
>>>>> This is definitely not correct except for the testing purposes.
>>>>>
>>>>> Currently we have these small projects in our main module:
>>>>> - kernel - library
>>>>> - GUI - should use the library=2C should be also an example of how to=
 use ti
>>>>
>>>> I don't agree. PDFedit =3D GUI for manipulating PDF documents.
>>>
>>> you clearly distinguish between gui and tools and
>>> think of pdfedit as GUI for manipulating pdf. I started to think of
>>> pdfedit as the library itself. GUI is only using the library. There is
>>> where we do not agree.
>>>
>>> """
>>> PDFedit =3D GUI for manipulating PDF documents.
>>> """
>>
>>> is 6 years old description=2C we should move forward.
>>
>> I think that we should stick with this description. 99% of user will
>> never use the library and the only thing they will see is the GUI.
>> Just look at the simple fact that the library was announced back in
>> December and there is still no package for it in any Linux distribution
>> I know of.
>>
>> Making GUI out of pdfedit module simply doesn't make any sense to me.
>>
>>> There is clearly application for the library so=2C imho=2C we should no=
t
>>> make differences between GUI and other usages.
>>
>> Yes we should make a difference=2C because we distribute GUI! We are not
>> distributing (except of Windows) tools for example.
>>
>>>>> - tools - should use the library=2C should be also an example of how =
to use ti
>>>>> - tests - directly test kernel library
>>>>>
>>>>
>>>>> When I look at it now=2C if we want to separate something we have to
>>>>> separate GUI as well! I am for this solution=2C but not for the parti=
al
>>>>> one separating only tools.
>>>>
>>>> This doesn't make sense. As I have already written above PDFedit =3D G=
UI
>>>> not kernel.
>>>> The fact that we have made the core functionality as library
>>>> which can be extracted doesn't make any change to the original
>>>> intention of our project.
>>>>
>>>> Tools on other hand=2C is something which doesn't have anything to do =
with
>>>> original project intention. It is a simple example how to use the core
>>>> library.
>>>
>>> See above why we disagree. Maybe we should reconsider the original
>>> intention of our project?
>>
>> Reconsider to what?
>>
>>>
>>> For example the original intention was for *nix users which are now a
>>> minor user group! (see stats of downloaded files=2C more than 70% are
>>> windows users)
>>
>> Sorry=2C but this is flawed argumentation. As you already written in the
>> other email sf.net statistics are download count only. This doesn't say
>> anything neither about usage nor about linux distribution users who form
>> the vast majority of PDFedit users (just check our support mailing list
>> posts - almost nobody compiles sources from CVS or download tarball).
>>
>>>>> However=2C i have to mention one thing. From my experience=2C many
>>>>> projects are very difficult to use because useful parts are all over
>>>>> the place and you need to build/install 5 things before you get the
>>>>> result.
>>>>
>>>>> Here=2C we will have one unusable part by itself (pdfedit-core-dev) a=
nd
>>>>> other useful things somewhere else. IMHO=2C this si less user frienly
>>>>> for most of our users!
>>>>
>>>> Sorry=2C I am not following you. What do you consider unusable about
>>>> pdfedit-core-dev? Have you ever tried to deploy and use it? (I mean as=
 a
>>>> standalone system library)
>>>
>>
>>> serious misunderstanding=2C i 100% support your idea to make
>>> pdfedit-core-dev! i was talking about a normal user who wants
>>> applications not libraries.
>>
>> He has pdfedit and possibility to run scripts for all we have in tools
>> currently (even though scripting usage sucks a bit - but this should be
>> different in the new version of GUI).
>>
>>> """
>>> unusable part by itself
>>> """
>>> you install it and it cannot do anything by itself (cannot be run).
>>
>> That is what libraries usually do =3B)
>>
>> [...]
>>>>>> I think that nobody would like to select only important parts to get
>>>>>> what he needs for a simple pdfedit-core-dev tool. Moreover when you
>>>>>> check our README you will find out that making a proper Makefile for
>>>>>> tools is really simple. But who reads README? I think almost nobody=
=2C
>>>>>> so making it clear in tools and provide something to copy&paste is
>>>>>> much better.
>>>>>
>>>>> This argument is silly=2C if we cannot be sure that ppl do not read
>>>>> README then we cannot be sure that somebody will read API
>>>>> documentation etc.
>>>>
>>>> Yes and face it=2C nobody does that. You have to serve everything if y=
ou
>>>> want people to use/understand...
>>>
>>
>>> You have to draw a reasonable line how to be user friendly. If
>>> something is good it does not need to give everybody everything=2C it
>>> only makes more mess.
>>
>> Sorry=2C I am loosing context. We were talking about how to use
>> pdfedit-core-dev and that clear README description is not enough because
>> almost nobody reads such documents and I was arguing that this is the
>> reason why tools should be put externally with Makefiles prepared for
>> pdfedit-core-dev (external library).
>>
>>>>>>> if not then something is wrong with our Makefiles.
>>>>>>
>>>>>> Could you be more specific? What is wrong?
>>>>>
>>>>> from previous email """ for g++ it should be easy using Makefiles fro=
m
>>>>> tools directory=2C shouldn't it? if not then something is wrong with =
our
>>>>> Makefiles. """
>>>>>
>>>>> If it cannot be reused easily something is wrong with them. Can they
>>>>> be reused easily?
>>>>
>>>> Sorry=2C still not clear to me. What is wrong. What do you mean by reu=
sed
>>>> easily? Have you looked at our makefile infrastructure and its
>>>> connection to the configure? Please go through it and come back with
>>>> specific arguments which we can deal with.
>>>>
>>>> I don't want to repeat myself=2C but look at what is necessary for
>>>> pdfedit-core-dev application to build and than compare what would be
>>>> necessary to extract from the PDFedit Makefiles...
>>>
>>
>>> Michal=2C try looking at our *nix building schema from user point of
>>> view=2C not from internal developer. I have something i want to reuse=
=2C
>>> if i cannot reuse it easily it is not very good.
>>
>> Makefile and configure are *project* specific files. Each project is
>> unique and has specific requirements. Therefore reusability term in this
>> context doesn't make too much sense to me. Of course you can copy some
>> parts and use it in a different project (e.g. proper boost or doxygen
>> detection) or you can reuse scheme of Makefile.rules/Makefile.flags for
>> clear project-wide build configuration but this is nothing I would call
>> reusability.
>>
>>> That is what i was trying to say all the time. I forgot the internal
>>> structure of our Makefiles (and i really do not want to learn it
>>> again)
>>
>> Please make familiar with something you are discussing about.
>>
>>> but if it cannot be reused=2C it is probably not so well. (Imho=2C
>>> i think it can be reused easily but you try to push your arguments :)
>>
>> Have you ever looked at the Linux kernel building system? I consider it
>> one of the best. But I don't thing that you can easily (or in some
>> reasonable time) extract only some parts (e.g. scheme for modules
>> building) out of it and reuse in a different project.
>>
>>>>>>> regarding (auto)configure it is up to the developers to extract
>>>>>>> important parts from our scripts because they will probably use
>>>>>>> other dependencies. maybe we can add a simple description to the
>>>>>>> scripts themselves.
>>>>>>
>>>>>> This shouldn't be necessary. Check the pdfedit-core-dev-config
>>>>>> script which sets proper compilation and linking flags. It is
>>>>>> provided by pdfedit-core-dev library. If you install this library
>>>>>> you have a guarantee that everything matches your system and you
>>>>>> don't have to play with configure.
>>>>>
>>>>> A developer has to specify libraries which are necessary. I think tha=
t
>>>>> ppl using our library for meaningful things will need also other
>>>>> libraries so they have to be able to change the scripts anyway!
>>>>
>>>> Which libraries you have in mind?
>>>> pdfedit-core-dev-config --libs returns all libraries for
>>>> pdfedit-core-dev linkage.
>>>
>>
>>> Developer is creating a new project=2C hmmm=2C he decides to use pdfedi=
t
>>> library and after that? the developer will probably also use other
>>> libraries (for GUI for example) so he has to change the configure
>>> scripts. do you understand now what i wanted to say?
>>
>> Yes and what I am saying all the time is that he doesn't need to bother
>> with our building system to accomplish that. All he needs to do is:
>>
>> Check for pdfedit-core-dev-config script (if it doesn't exist then he
>> needs to install the pdfedit-core-dev library). If it exists then he
>> needs:
>> PDFEDIT_CLFAGS =3D $(shell pdfedit-core-dev-config --cflags)
>> PDFEDIT_LDFLAGS =3D $(shell pdfedit-core-dev-config --libs)
>> CFLAGS =3D $(PROJECT_CFLAGS) $(PDFEDIT_CLFAGS)
>> LDFLAGS =3D $(PROJECT_LDFLAGS) $(PDFEDIT_LDFLAGS)
>>
>> See? This is explained in our README file all I would like to have is
>> that tools would use the same scheme.
>> The pdfedit-core-dev detection can be covered by a simple configure
>> script (I can prepare one).
>>
>>>
>>> I will summarize my views on the 2 main approaches:
>>> 1. not separate
>>> - evertyhing is in one place=2C more developer friendly=2C more user mo=
re friendly
>>> - clear examples of usage GUI=2C tools
>>> - step-by-step for ppl who wants to create their own applications
>>
>> Except for a simple example how to build their own projects (read as no
>> Makefile skeleton).
>>
>>>
>>> 2. separate
>>> - less user friendly=2C he needs to do more things to get e.g. GUI comp=
iled
>>
>> You are still discussing about GUI which I don't want to put out of the
>> way exactly for this reason.
>> If you put tools out of the main project you don't have to care about
>> anything else but tools which you are interested in. Why would you want
>> to download whole sources (testing documents=2C tests=2C GUI=2C kernel=
=2C
>> documentation...)? See?
>>
>>> - clear examples of usage GUI=2C tools - the same as in 1) according to=
 my suggestion
>>> - ""probably"" more reusable *nix Makefiles
>>
>> Why probably. If you have a Makefile (skeleton one mentioned above) you
>> can use it as it is.
>>
>> --
>> Michal Hocko
>>
>> ------------------------------------------------------------------------=
------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-=
Day
>> trial. Simplify your report design=2C integration and deployment - and f=
ocus on
>> what you do best=2C core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Pdfedit-devel mailing list
>> Pdfedit-devel@...
>> https://lists.sourceforge.net/lists/listinfo/pdfedit-devel
>
> --
> Michal Hocko
 		 	   		  =0A=
_________________________________________________________________=0A=
Hotmail: Trusted email with Microsoft=92s powerful SPAM protection.=0A=
http://clk.atdmt.com/GBL/go/177141664/direct/01/=

On Fri, Oct 09, 2009 at 06:21:35AM +0000, Jozef Misutka wrote:
> ----------------------------------------
> > Date: Thu=2C 8 Oct 2009 14:08:09 +0200
> > From: mstsxfx@...
> > To: misutkajunior@...
> > CC: martin@... pdfedit-devel@...
> > Subject: Re: [RFC] tools out of pdfedit module?
> >
> > Any conclusion to this discussion?
> 
> i told you my expectations and sadly they do not match with yours. 

Maybe they don't match, because we have different priorities. But this
has to be discussed.  Unfortunately discussion ended (like usual) with
not replied questions...

Look, I don't have a strong opinion on tools - this is why I opened this
question in the first place. My feeling is that they should be out of
the core source because I see some advantages from that.

The only strong opposition from my side is to excluding GUI from the
core package because I don't think that this would have any gain to our
project (see all arguments in the thread).

I would like to hear back from Martin as well. If he agrees with in tree
tools, I have no problem with that.

> the conclusion is clear then.

And that is?

> 
> 
> >
> > On Mon=2C Sep 14=2C 2009 at 10:11:08AM +0200=2C Michal Hocko wrote:
> >> On Sun=2C Sep 13=2C 2009 at 06:04:16PM +0000=2C Jozef Misutka wrote:
> >>>> On Sun=2C Sep 13=2C 2009 at 11:21:44AM +0000=2C Jozef Misutka wrote:
> >>>>>> On Sat=2C Sep 12=2C 2009 at 02:09:04PM +0000=2C Jozef Misutka wrote:
> >>>>>>>> On Thu=2C Sep 10=2C 2009 at 06:32:14PM +0000=2C Jozef Misutka wrot=
> e:
> >>>>>>>>>> On Thu=2C Sep 10=2C 2009 at 03:40:19PM +0000=2C Jozef Misutka wr=
> ote:
> >>>>>> [...]
> >>>>>>>>>>>> I am thinking that=2C maybe=2C we should get tools out of the =
> pdfedit source
> >>>>>>>>>>>> completely and create a separate module for it in our CVS. The=
>  rationale
> >>>>>>>>>>>> is that we want to show how to use our pdfedit-dev-core librar=
> y but it
> >>>>>>>>>>>> is not used if the source is in src/tools - at least from buil=
> ding POV.
> >>>>>>>>>>>> If we make it a separate module we can use proper Makefile
> >>>>>>>>>>>> infrastructure required for proper building and linking with t=
> he
> >>>>>>>>>>>> library.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Just an idea... What do you think?
> >> [...]
> >>>> It looks like you are mixing two things. pdfedit-core-dev refers to th=
> e
> >>>> _external_ library! Something you have installed on your system and yo=
> u
> >>>> can easily build programs up on. Source for it is a part of PDFedit
> >>>> project. There is no reason why GUI/tests should build against an
> >>>
> >>> It does not make sense for our unit tests to use a library externally=
> =3B
> >>> i hope that is clear.
> >>
> >> Sure=2C it is project internall stuff.
> >>
> >>>
> >>>> external library if it is available directly.
> >>>
> >>> Well=2C when tools have the library available too why should they not
> >>> link against it then?
> >>
> >> Because we want to make this an _example_ on how to use the library.
> >>>From my POV this means 2 things: proper code usage and proper Makefile
> >> to build the code.
> >>
> >>>
> >>> See below.
> >>>
> >>>>
> >>>>> This is definitely not correct except for the testing purposes.
> >>>>>
> >>>>> Currently we have these small projects in our main module:
> >>>>> - kernel - library
> >>>>> - GUI - should use the library=2C should be also an example of how to=
>  use ti
> >>>>
> >>>> I don't agree. PDFedit =3D GUI for manipulating PDF documents.
> >>>
> >>> you clearly distinguish between gui and tools and
> >>> think of pdfedit as GUI for manipulating pdf. I started to think of
> >>> pdfedit as the library itself. GUI is only using the library. There is
> >>> where we do not agree.
> >>>
> >>> """
> >>> PDFedit =3D GUI for manipulating PDF documents.
> >>> """
> >>
> >>> is 6 years old description=2C we should move forward.
> >>
> >> I think that we should stick with this description. 99% of user will
> >> never use the library and the only thing they will see is the GUI.
> >> Just look at the simple fact that the library was announced back in
> >> December and there is still no package for it in any Linux distribution
> >> I know of.
> >>
> >> Making GUI out of pdfedit module simply doesn't make any sense to me.
> >>
> >>> There is clearly application for the library so=2C imho=2C we should no=
> t
> >>> make differences between GUI and other usages.
> >>
> >> Yes we should make a difference=2C because we distribute GUI! We are not
> >> distributing (except of Windows) tools for example.
> >>
> >>>>> - tools - should use the library=2C should be also an example of how =
> to use ti
> >>>>> - tests - directly test kernel library
> >>>>>
> >>>>
> >>>>> When I look at it now=2C if we want to separate something we have to
> >>>>> separate GUI as well! I am for this solution=2C but not for the parti=
> al
> >>>>> one separating only tools.
> >>>>
> >>>> This doesn't make sense. As I have already written above PDFedit =3D G=
> UI
> >>>> not kernel.
> >>>> The fact that we have made the core functionality as library
> >>>> which can be extracted doesn't make any change to the original
> >>>> intention of our project.
> >>>>
> >>>> Tools on other hand=2C is something which doesn't have anything to do =
> with
> >>>> original project intention. It is a simple example how to use the core
> >>>> library.
> >>>
> >>> See above why we disagree. Maybe we should reconsider the original
> >>> intention of our project?
> >>
> >> Reconsider to what?
> >>
> >>>
> >>> For example the original intention was for *nix users which are now a
> >>> minor user group! (see stats of downloaded files=2C more than 70% are
> >>> windows users)
> >>
> >> Sorry=2C but this is flawed argumentation. As you already written in the
> >> other email sf.net statistics are download count only. This doesn't say
> >> anything neither about usage nor about linux distribution users who form
> >> the vast majority of PDFedit users (just check our support mailing list
> >> posts - almost nobody compiles sources from CVS or download tarball).
> >>
> >>>>> However=2C i have to mention one thing. From my experience=2C many
> >>>>> projects are very difficult to use because useful parts are all over
> >>>>> the place and you need to build/install 5 things before you get the
> >>>>> result.
> >>>>
> >>>>> Here=2C we will have one unusable part by itself (pdfedit-core-dev) a=
> nd
> >>>>> other useful things somewhere else. IMHO=2C this si less user frienly
> >>>>> for most of our users!
> >>>>
> >>>> Sorry=2C I am not following you. What do you consider unusable about
> >>>> pdfedit-core-dev? Have you ever tried to deploy and use it? (I mean as=
>  a
> >>>> standalone system library)
> >>>
> >>
> >>> serious misunderstanding=2C i 100% support your idea to make
> >>> pdfedit-core-dev! i was talking about a normal user who wants
> >>> applications not libraries.
> >>
> >> He has pdfedit and possibility to run scripts for all we have in tools
> >> currently (even though scripting usage sucks a bit - but this should be
> >> different in the new version of GUI).
> >>
> >>> """
> >>> unusable part by itself
> >>> """
> >>> you install it and it cannot do anything by itself (cannot be run).
> >>
> >> That is what libraries usually do =3B)
> >>
> >> [...]
> >>>>>> I think that nobody would like to select only important parts to get
> >>>>>> what he needs for a simple pdfedit-core-dev tool. Moreover when you
> >>>>>> check our README you will find out that making a proper Makefile for
> >>>>>> tools is really simple. But who reads README? I think almost nobody=
> =2C
> >>>>>> so making it clear in tools and provide something to copy&paste is
> >>>>>> much better.
> >>>>>
> >>>>> This argument is silly=2C if we cannot be sure that ppl do not read
> >>>>> README then we cannot be sure that somebody will read API
> >>>>> documentation etc.
> >>>>
> >>>> Yes and face it=2C nobody does that. You have to serve everything if y=
> ou
> >>>> want people to use/understand...
> >>>
> >>
> >>> You have to draw a reasonable line how to be user friendly. If
> >>> something is good it does not need to give everybody everything=2C it
> >>> only makes more mess.
> >>
> >> Sorry=2C I am loosing context. We were talking about how to use
> >> pdfedit-core-dev and that clear README description is not enough because
> >> almost nobody reads such documents and I was arguing that this is the
> >> reason why tools should be put externally with Makefiles prepared for
> >> pdfedit-core-dev (external library).
> >>
> >>>>>>> if not then something is wrong with our Makefiles.
> >>>>>>
> >>>>>> Could you be more specific? What is wrong?
> >>>>>
> >>>>> from previous email """ for g++ it should be easy using Makefiles fro=
> m
> >>>>> tools directory=2C shouldn't it? if not then something is wrong with =
> our
> >>>>> Makefiles. """
> >>>>>
> >>>>> If it cannot be reused easily something is wrong with them. Can they
> >>>>> be reused easily?
> >>>>
> >>>> Sorry=2C still not clear to me. What is wrong. What do you mean by reu=
> sed
> >>>> easily? Have you looked at our makefile infrastructure and its
> >>>> connection to the configure? Please go through it and come back with
> >>>> specific arguments which we can deal with.
> >>>>
> >>>> I don't want to repeat myself=2C but look at what is necessary for
> >>>> pdfedit-core-dev application to build and than compare what would be
> >>>> necessary to extract from the PDFedit Makefiles...
> >>>
> >>
> >>> Michal=2C try looking at our *nix building schema from user point of
> >>> view=2C not from internal developer. I have something i want to reuse=
> =2C
> >>> if i cannot reuse it easily it is not very good.
> >>
> >> Makefile and configure are *project* specific files. Each project is
> >> unique and has specific requirements. Therefore reusability term in this
> >> context doesn't make too much sense to me. Of course you can copy some
> >> parts and use it in a different project (e.g. proper boost or doxygen
> >> detection) or you can reuse scheme of Makefile.rules/Makefile.flags for
> >> clear project-wide build configuration but this is nothing I would call
> >> reusability.
> >>
> >>> That is what i was trying to say all the time. I forgot the internal
> >>> structure of our Makefiles (and i really do not want to learn it
> >>> again)
> >>
> >> Please make familiar with something you are discussing about.
> >>
> >>> but if it cannot be reused=2C it is probably not so well. (Imho=2C
> >>> i think it can be reused easily but you try to push your arguments :)
> >>
> >> Have you ever looked at the Linux kernel building system? I consider it
> >> one of the best. But I don't thing that you can easily (or in some
> >> reasonable time) extract only some parts (e.g. scheme for modules
> >> building) out of it and reuse in a different project.
> >>
> >>>>>>> regarding (auto)configure it is up to the developers to extract
> >>>>>>> important parts from our scripts because they will probably use
> >>>>>>> other dependencies. maybe we can add a simple description to the
> >>>>>>> scripts themselves.
> >>>>>>
> >>>>>> This shouldn't be necessary. Check the pdfedit-core-dev-config
> >>>>>> script which sets proper compilation and linking flags. It is
> >>>>>> provided by pdfedit-core-dev library. If you install this library
> >>>>>> you have a guarantee that everything matches your system and you
> >>>>>> don't have to play with configure.
> >>>>>
> >>>>> A developer has to specify libraries which are necessary. I think tha=
> t
> >>>>> ppl using our library for meaningful things will need also other
> >>>>> libraries so they have to be able to change the scripts anyway!
> >>>>
> >>>> Which libraries you have in mind?
> >>>> pdfedit-core-dev-config --libs returns all libraries for
> >>>> pdfedit-core-dev linkage.
> >>>
> >>
> >>> Developer is creating a new project=2C hmmm=2C he decides to use pdfedi=
> t
> >>> library and after that? the developer will probably also use other
> >>> libraries (for GUI for example) so he has to change the configure
> >>> scripts. do you understand now what i wanted to say?
> >>
> >> Yes and what I am saying all the time is that he doesn't need to bother
> >> with our building system to accomplish that. All he needs to do is:
> >>
> >> Check for pdfedit-core-dev-config script (if it doesn't exist then he
> >> needs to install the pdfedit-core-dev library). If it exists then he
> >> needs:
> >> PDFEDIT_CLFAGS =3D $(shell pdfedit-core-dev-config --cflags)
> >> PDFEDIT_LDFLAGS =3D $(shell pdfedit-core-dev-config --libs)
> >> CFLAGS =3D $(PROJECT_CFLAGS) $(PDFEDIT_CLFAGS)
> >> LDFLAGS =3D $(PROJECT_LDFLAGS) $(PDFEDIT_LDFLAGS)
> >>
> >> See? This is explained in our README file all I would like to have is
> >> that tools would use the same scheme.
> >> The pdfedit-core-dev detection can be covered by a simple configure
> >> script (I can prepare one).
> >>
> >>>
> >>> I will summarize my views on the 2 main approaches:
> >>> 1. not separate
> >>> - evertyhing is in one place=2C more developer friendly=2C more user mo=
> re friendly
> >>> - clear examples of usage GUI=2C tools
> >>> - step-by-step for ppl who wants to create their own applications
> >>
> >> Except for a simple example how to build their own projects (read as no
> >> Makefile skeleton).
> >>
> >>>
> >>> 2. separate
> >>> - less user friendly=2C he needs to do more things to get e.g. GUI comp=
> iled
> >>
> >> You are still discussing about GUI which I don't want to put out of the
> >> way exactly for this reason.
> >> If you put tools out of the main project you don't have to care about
> >> anything else but tools which you are interested in. Why would you want
> >> to download whole sources (testing documents=2C tests=2C GUI=2C kernel=
> =2C
> >> documentation...)? See?
> >>
> >>> - clear examples of usage GUI=2C tools - the same as in 1) according to=
>  my suggestion
> >>> - ""probably"" more reusable *nix Makefiles
> >>
> >> Why probably. If you have a Makefile (skeleton one mentioned above) you
> >> can use it as it is.
> >>
> >> --
> >> Michal Hocko
> >>
> >> ------------------------------------------------------------------------=
> ------
> >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-=
> Day
> >> trial. Simplify your report design=2C integration and deployment - and f=
> ocus on
> >> what you do best=2C core application coding. Discover what's new with
> >> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> >> _______________________________________________
> >> Pdfedit-devel mailing list
> >> Pdfedit-devel@...
> >> https://lists.sourceforge.net/lists/listinfo/pdfedit-devel
> >
> > --
> > Michal Hocko
>  		 	   		  =0A=
> _________________________________________________________________=0A=
> Hotmail: Trusted email with Microsoft=92s powerful SPAM protection.=0A=
> http://clk.atdmt.com/GBL/go/177141664/direct/01/=

-- 
Michal Hocko

>>>>>>>>>>> I am thinking that, maybe, we should get tools out of the pdfedit source
>>>>>>>>>>> completely and create a separate module for it in our CVS. The rationale
>>>>>>>>>>> is that we want to show how to use our pdfedit-dev-core library but it
>>>>>>>>>>> is not used if the source is in src/tools - at least from building POV.
>>>>>>>>>>> If we make it a separate module we can use proper Makefile
>>>>>>>>>>> infrastructure required for proper building and linking with the
>>>>>>>>>>> library.

Should we separate the GUI as well?

Currently the intentions are rather to unite stuff - to move (or rather
create a new one) qt4 gui inside the head and change scripts to be able to
switch the GUI.

>>>> We have kernel which is sometimes used as a library and sometimes used
>>>> as sources directly.
>>> This is not true. GUI _links_ to the libraries.
>> I called it "directly".

Kernel now uses static linking and it is used like a library - as is STL
for example, where there is minimum of any "executable library code", since
almost everything is done by templates.

Question is: can the kernel be recompiled as a dynamic library, so it can
be truly reused in multiple programs on same system?

Basically now (and even if we will separate tools and/or gui) both tools
and gui use libkernel.a and appropriate headers and they do not care from
where they come. If we want to split it, we just need to change the include
paths.....

So the real question is whether to split the makefile system - now we have
one make system that have plenty of parameters (whether to build tools,
gui, whether to build pdfedit-core-dev, ...)

and the suggestion is to split things up - we'll have one makefile system
that will build libkernel.a and then install it along with headers. GUI and
tools will then have this as dependencies. The main change will be in the
makefiel structure.

>> I will summarize my views on the 2 main approaches:
>>
>>
>>
>> 1. not separate
>> - evertyhing is in one place, more developer friendly, more user more friendly
>> - clear examples of usage GUI, tools
>> - step-by-step for ppl who wants to create their own applications

Easier for end user to compile, just ./configure && make, no need to care
about any libraries or whatever

>> 2. separate
>>
>> - less user friendly, he needs to do more things to get e.g. GUI compiled
>>
>> - clear examples of usage GUI, tools - the same as in 1) according to my suggestion
>> - ""probably"" more reusable *nix Makefiles

Easier for developers - they just take tools or gui as base of their new
program and treat pdfedit-core-dev as "some backbox with headers"

Both approach have its advantages and disadvantages.
1. For windows users: they just download binaries, they don't care.
2. For people thet get pdfedit through repository of their favorite distro:
they just install it, dependencies get installed automatically, they don't
care.

3. Developer that want to create something based on our codebase: I guess
they'll prefer "separated" approach, as it will be a bit easier for them.
4. End users that want to compile pdfedit from source: I guess they'll
prefer to have everything in one tree, as it will be a bit easier for them.

So question is - do we want to make it slightly easier for group 3 at cost
of making it slightly harder for group 4, or vice versa?

Martin Petricek

-- 


   GPG/PGP Public key:  http://www.petricek.net/petricm.pgp
Fingerprint 6AA8 FFCE C061 1CB2 55F0  A1F3 3AA9 EB4F BD50 C1B8
/------------------------------------------------------------\
| WWW:                    http://www.petricek.net/           |
\------------------------------------------------------------/

On Wed, Oct 21, 2009 at 04:07:42AM +0200, Martin Petricek wrote:
> >>>>>>>>>>> I am thinking that, maybe, we should get tools out of the pdfedit source
> >>>>>>>>>>> completely and create a separate module for it in our CVS. The rationale
> >>>>>>>>>>> is that we want to show how to use our pdfedit-dev-core library but it
> >>>>>>>>>>> is not used if the source is in src/tools - at least from building POV.
> >>>>>>>>>>> If we make it a separate module we can use proper Makefile
> >>>>>>>>>>> infrastructure required for proper building and linking with the
> >>>>>>>>>>> library.
> 
> Should we separate the GUI as well?

This is what Jozo is suggesting and I don't like the idea much because
this project is (IMHO) about GUI to manipulate with PDF documents. The
library wasn't intention in the beginning but it was designed to be
split from gui. That is why we should distribute it also as a separate
package.

Tools on the other hand is just a collection of simple examples how to
use a library. That was the initial trigger for my question whether we
should consider getting it out of our tree. It would have several
advantages:
	- library sources would be used as expected (not directly by
	  through system wide installation)
	- we would have a collection of ABI checkers
	- maybe we can have some contributions (people tend to develop
	  one-purpose things much more than contribute to an existing
	  project directly)

> Currently the intentions are rather to unite stuff - to move (or rather
> create a new one) qt4 gui inside the head and change scripts to be able to
> switch the GUI.

And I think that this makes our life and also distributors life easier.
Especially if everything is easily manageable by ./configure

We are not distributing tools so I don't see any problem putting it out
of the main tree. Well, more precisely, we are not distributing it for
other than windows native environment (and, honestly, this is done only
because there is nothing else to distribute there).

> 
> >>>> We have kernel which is sometimes used as a library and sometimes used
> >>>> as sources directly.
> >>> This is not true. GUI _links_ to the libraries.
> >> I called it "directly".
> 
> Kernel now uses static linking and it is used like a library - as is STL
> for example, where there is minimum of any "executable library code", since
> almost everything is done by templates.
> 
> Question is: can the kernel be recompiled as a dynamic library, so it can
> be truly reused in multiple programs on same system?

I think that dynamic linking would be little bit problem but I don't
think that we need that at the moment. This is not a library which would
be linked to many binaries at the same time... So the benefit from
shared loading and smaller binaries is not that big.

Also we are not at the stage where we have stable ABI. I assume that we
will have several releases where each one will break previous ABI
(especially due to our template design and much of the code in header
files). Managing static libraries is therefore easier for both us and
the code base users.

> 
> Basically now (and even if we will separate tools and/or gui) both tools
> and gui use libkernel.a and appropriate headers and they do not care from
> where they come. If we want to split it, we just need to change the include
> paths.....

No, include paths are not a problem. With some minor changes to gui
makefiles we can do it at this moment.

> 
> So the real question is whether to split the makefile system - now we have
> one make system that have plenty of parameters (whether to build tools,
> gui, whether to build pdfedit-core-dev, ...)
> 
> and the suggestion is to split things up - we'll have one makefile system
> that will build libkernel.a and then install it along with headers. GUI and
> tools will then have this as dependencies. The main change will be in the
> makefiel structure.

The main change would be that you need more repository to look in when
you want to build PDFedit (GUI) from sources.

> 
> >> I will summarize my views on the 2 main approaches:
> >>
> >>
> >>
> >> 1. not separate
> >> - evertyhing is in one place, more developer friendly, more user more friendly

true

> >> - clear examples of usage GUI, tools
> >> - step-by-step for ppl who wants to create their own applications

Not that much true. If tools are inside the tree then we should link
against in tree libraries and not those which are system wide. Why?
Because it is rather non intuitive that you need to build the rest of
the system, run make install and then you can build your favorite tool.
I don't know about any project doing this and I can see reasons for
that.

On the other hand, if we link against in tree libraries then we don't
teach anybody how he can do it by himself when he needs to build some
application. People will end up adding such a code to the tools/ and
link them in tree which is obviously not good for the system wide
installation.

> 
> Easier for end user to compile, just ./configure && make, no need to care
> about any libraries or whatever
> 
> >> 2. separate
> >>
> >> - less user friendly, he needs to do more things to get e.g. GUI compiled

not only compiled but also download sources and configure...

> >>
> >> - clear examples of usage GUI, tools - the same as in 1) according to my suggestion
> >> - ""probably"" more reusable *nix Makefiles
> 
> Easier for developers - they just take tools or gui as base of their new
> program and treat pdfedit-core-dev as "some backbox with headers"
> 
> Both approach have its advantages and disadvantages.
> 1. For windows users: they just download binaries, they don't care.
> 2. For people thet get pdfedit through repository of their favorite distro:
> they just install it, dependencies get installed automatically, they don't
> care.
> 
> 3. Developer that want to create something based on our codebase: I guess
> they'll prefer "separated" approach, as it will be a bit easier for them.
> 4. End users that want to compile pdfedit from source: I guess they'll
> prefer to have everything in one tree, as it will be a bit easier for them.
> 
> So question is - do we want to make it slightly easier for group 3 at cost
> of making it slightly harder for group 4, or vice versa?

We definitely don't want to make life harder for those who compile from
sources (distributors and random users who don't want to rely on
distribution outdated version). Making them download more different
sources from different trees is PITA.


>
> Martin Petricek
> 
> -- 
> 
> 
>    GPG/PGP Public key:  http://www.petricek.net/petricm.pgp
> Fingerprint 6AA8 FFCE C061 1CB2 55F0  A1F3 3AA9 EB4F BD50 C1B8
> /------------------------------------------------------------\
> | WWW:                    http://www.petricek.net/           |
> \------------------------------------------------------------/

-- 
Michal Hocko

Michal Hocko wrote:
> Hi Martin,
> I was thinking how to make our building system to better reflect
> configuration change. Attached you can find a patch which tries to
> implement this.
> 
> Could you have a look at it and let me know what you think about that?
> 
> Thanks

I think we should replace the suffix rules with pattern rules using this
patch. The suffix rules are deprecated and IMHO less legible.

For gui compilation, config.pro should be added to list of files that
should trigger recompilation, but since the makefile for gui compilation is
created with qmake, I am not sure whether this is possible (since
Makefile.rules is not included)

But adding it to Makefile in src as dependency for $(GUIROOT)/Makefile.qt
could do the trick. At least it will re-generate the GUI Makefile

Martin Petricek

-- 


   GPG/PGP Public key:  http://www.petricek.net/petricm.pgp
Fingerprint 6AA8 FFCE C061 1CB2 55F0  A1F3 3AA9 EB4F BD50 C1B8
/------------------------------------------------------------\
| WWW:                    http://www.petricek.net/           |
\------------------------------------------------------------/

On Wed, Oct 21, 2009 at 02:02:52AM +0200, Martin Petricek wrote:
> Michal Hocko wrote:
> > Hi Martin,
> > I was thinking how to make our building system to better reflect
> > configuration change. Attached you can find a patch which tries to
> > implement this.
> > 
> > Could you have a look at it and let me know what you think about that?
> > 
> > Thanks
> 
> I think we should replace the suffix rules with pattern rules using this
> patch. The suffix rules are deprecated and IMHO less legible.

Thanks for looking into it.
Patch is in the CVS now.
 
> For gui compilation, config.pro should be added to list of files that
> should trigger recompilation, but since the makefile for gui compilation is
> created with qmake, I am not sure whether this is possible (since
> Makefile.rules is not included)

You can use EXTRA_REBUILD_FORCE_FILES defined for GUI only to do that.

> 
> But adding it to Makefile in src as dependency for $(GUIROOT)/Makefile.qt
> could do the trick. At least it will re-generate the GUI Makefile
> 
> Martin Petricek
> 
> -- 
> 
> 
>    GPG/PGP Public key:  http://www.petricek.net/petricm.pgp
> Fingerprint 6AA8 FFCE C061 1CB2 55F0  A1F3 3AA9 EB4F BD50 C1B8
> /------------------------------------------------------------\
> | WWW:                    http://www.petricek.net/           |
> \------------------------------------------------------------/

-- 
Michal Hocko

On Sun, Oct 11, 2009 at 11:40:44PM +0200, Martin Petricek wrote:
> >> gcc supports this standard so I have no objection. The question,
> >> however, is what is the state of other compilers?
> > 
> > http://wiki.apache.org/stdcxx/C++0xCompilerSupport
> > 
> > It seems that many compilers don't support a big part of this standard
> > and even gcc brought many features in post 4.3 versions).
> 
> Seems the only thing widely supported is long long and extern templates
> While gcc 4.3 is not that new, there are still many places where older
> versions are used (4.1, 4.2, ...) and there are other compilers (intel,
> msvc) with only newest version having some support. So I'd stick with older
> standard for now. Perhaps except with long long, since we may need 64bit
> integer sometimes...
> 
> Is there any feature in c++0x that will make our code substantially
> better/easier/more legible?

Jozo?

If not I will commit the patch in the original form.

> 
> > I would be rather conservative here and stick to the older standard and
> > move to the newer one later when necessary (e.g. when some of the
> > library requires that).
> > 
> > What is your opinion Martin?
> 
> I'd stick with older standard too
> 
> Martin Petricek
> 
> -- 
> 
> 
>    GPG/PGP Public key:  http://www.petricek.net/petricm.pgp
> Fingerprint 6AA8 FFCE C061 1CB2 55F0  A1F3 3AA9 EB4F BD50 C1B8
> /------------------------------------------------------------\
> | WWW:                    http://www.petricek.net/           |
> \------------------------------------------------------------/
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Pdfedit-devel mailing list
> Pdfedit-devel@...
> https://lists.sourceforge.net/lists/listinfo/pdfedit-devel

-- 
Michal Hocko

> Date: Fri, 16 Oct 2009 09:11:58 +0200
> From: mstsxfx@...
> To: misutkajunior@...
> CC: pdfedit-devel@...
> Subject: Re: [RFC Patch] force c/c++ standard for compilation
> 
> On Sun, Oct 11, 2009 at 11:40:44PM +0200, Martin Petricek wrote:
> > >> gcc supports this standard so I have no objection. The question,
> > >> however, is what is the state of other compilers?
> > > 
> > > http://wiki.apache.org/stdcxx/C++0xCompilerSupport
> > > 
> > > It seems that many compilers don't support a big part of this standard
> > > and even gcc brought many features in post 4.3 versions).
> > 
> > Seems the only thing widely supported is long long and extern templates
> > While gcc 4.3 is not that new, there are still many places where older
> > versions are used (4.1, 4.2, ...) and there are other compilers (intel,
> > msvc) with only newest version having some support. So I'd stick with older
> > standard for now. Perhaps except with long long, since we may need 64bit
> > integer sometimes...
> > 
> > Is there any feature in c++0x that will make our code substantially
> > better/easier/more legible?
> 

i am not sure what are you asking... whether we will use c++ features from TR1 from tomorrow? no, because it breaks compilation on todays compilers, as you said correctly.  no, because it is only TR. no, because we are using boost which implements many features from TR itself but is also backward compatible.

however my point was, that the standard is in most cases backward compatible (it does NOT change the behaviour of c++ on many places) so why not to use it?

Nevertheless, to avoid any problems/misunderstandigs etc, please use the spec you want.

/jozo



> Jozo?
> 
> If not I will commit the patch in the original form.
> 
> > 
> > > I would be rather conservative here and stick to the older standard and
> > > move to the newer one later when necessary (e.g. when some of the
> > > library requires that).
> > > 
> > > What is your opinion Martin?
> > 
> > I'd stick with older standard too
> > 
> > Martin Petricek
> > 
> > -- 
> > 
> > 
> >    GPG/PGP Public key:  http://www.petricek.net/petricm.pgp
> > Fingerprint 6AA8 FFCE C061 1CB2 55F0  A1F3 3AA9 EB4F BD50 C1B8
> > /------------------------------------------------------------\
> > | WWW:                    http://www.petricek.net/           |
> > \------------------------------------------------------------/
> > 
> > ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay 
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > Pdfedit-devel mailing list
> > Pdfedit-devel@...
> > https://lists.sourceforge.net/lists/listinfo/pdfedit-devel
> 
> -- 
> Michal Hocko
 		 	   		  
_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/171222986/direct/01/

On Fri, Oct 16, 2009 at 12:18:42PM +0000, Jozef Misutka wrote:
> > On Sun, Oct 11, 2009 at 11:40:44PM +0200, Martin Petricek wrote:
> > > >> gcc supports this standard so I have no objection. The question,
> > > >> however, is what is the state of other compilers?
> > > > 
> > > > http://wiki.apache.org/stdcxx/C++0xCompilerSupport
> > > > 
> > > > It seems that many compilers don't support a big part of this standard
> > > > and even gcc brought many features in post 4.3 versions).
> > > 
> > > Seems the only thing widely supported is long long and extern templates
> > > While gcc 4.3 is not that new, there are still many places where older
> > > versions are used (4.1, 4.2, ...) and there are other compilers (intel,
> > > msvc) with only newest version having some support. So I'd stick with older
> > > standard for now. Perhaps except with long long, since we may need 64bit
> > > integer sometimes...
> > > 
> > > Is there any feature in c++0x that will make our code substantially
> > > better/easier/more legible?
> > 
> 
> i am not sure what are you asking... 

You have suggested c++0x rathet than c++98 so I was interested in
technical reasoning for that. I am certainly not an expert in this
area...

> whether we will use c++ features from TR1 from tomorrow? no, because
> it breaks compilation on todays compilers, as you said correctly.  no,
> because it is only TR. no, because we are using boost which implements
> many features from TR itself but is also backward compatible.

So no reason to use c++0x, right?

> 
> however my point was, that the standard is in most cases backward
> compatible (it does NOT change the behaviour of c++ on many places) so
> why not to use it?

Because you may use features which are not supported in older compilers
and you will not get any warning/error from that which breaks
compatibility. The purpose of this patch is exactly to prevent from
that and so we should find nice balance between what we need and what is
widly supported.

> 
> Nevertheless, to avoid any problems/misunderstandigs etc, please use
> the spec you want.

If there is no better idea I will go with c++98.

-- 
Michal Hocko

On Fri, Oct 16, 2009 at 02:27:19PM +0200, Michal Hocko wrote:
> On Fri, Oct 16, 2009 at 12:18:42PM +0000, Jozef Misutka wrote:
> > > On Sun, Oct 11, 2009 at 11:40:44PM +0200, Martin Petricek wrote:
> > > > >> gcc supports this standard so I have no objection. The question,
> > > > >> however, is what is the state of other compilers?
> > > > > 
> > > > > http://wiki.apache.org/stdcxx/C++0xCompilerSupport
> > > > > 
> > > > > It seems that many compilers don't support a big part of this standard
> > > > > and even gcc brought many features in post 4.3 versions).
> > > > 
> > > > Seems the only thing widely supported is long long and extern templates
> > > > While gcc 4.3 is not that new, there are still many places where older
> > > > versions are used (4.1, 4.2, ...) and there are other compilers (intel,
> > > > msvc) with only newest version having some support. So I'd stick with older
> > > > standard for now. Perhaps except with long long, since we may need 64bit
> > > > integer sometimes...
> > > > 
> > > > Is there any feature in c++0x that will make our code substantially
> > > > better/easier/more legible?
> > > 
> > 
> > i am not sure what are you asking... 
> 
> You have suggested c++0x rathet than c++98 so I was interested in
> technical reasoning for that. I am certainly not an expert in this
> area...
> 
> > whether we will use c++ features from TR1 from tomorrow? no, because
> > it breaks compilation on todays compilers, as you said correctly.  no,
> > because it is only TR. no, because we are using boost which implements
> > many features from TR itself but is also backward compatible.
> 
> So no reason to use c++0x, right?
> 
> > 
> > however my point was, that the standard is in most cases backward
> > compatible (it does NOT change the behaviour of c++ on many places) so
> > why not to use it?
> 
> Because you may use features which are not supported in older compilers
> and you will not get any warning/error from that which breaks
> compatibility. The purpose of this patch is exactly to prevent from
> that and so we should find nice balance between what we need and what is
> widly supported.
> 
> > 
> > Nevertheless, to avoid any problems/misunderstandigs etc, please use
> > the spec you want.
> 
> If there is no better idea I will go with c++98.

Patch is in the CVS.

-- 
Michal Hocko

On Fri, Oct 09, 2009 at 03:23:55PM +0000, Jozef Misutka wrote:
> 
> hi,
> 
> after removing 
> 
> RCS file: /cvsroot/pdfedit/pdfedit/src/xpdf/xpdf/PDFDoc.cc,v
> retrieving revision 1.6
> diff -r1.6 PDFDoc.cc
> 282d281
> <   assert(!(secHdlr && !ret));
>
> kernel tests on all of our test files run without crashing. michal, can you  comment it out (at least)? 

PDFDoc.{cc,h} is not maintained as I've already written in the off-list
email so feel free to remove this.
I would strongly discourage you from using this class though.

> it fails when executing one of our tests. It was not so easy as it
> might seem to put it to this state :) next step would be to check the
> results and improve them.

Sorry, I don't get what you are trying to say.

> 
> 2michal: would it be possible to have this check also on linux using
> any (maybe already existing) script?

Which check? Sorry, I don't understand.

> 
> thx,
> jozo

-- 
Michal Hocko

<20091009153547.GB20764@...>
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0




----------------------------------------
> Date: Fri=2C 9 Oct 2009 17:35:47 +0200
> From: mstsxfx@...
> To: misutkajunior@...
> CC: pdfedit-devel@...
> Subject: Re: kernel unit tests
>
> On Fri=2C Oct 09=2C 2009 at 03:23:55PM +0000=2C Jozef Misutka wrote:
>>
>> hi=2C
>>
>> after removing
>>
>> RCS file: /cvsroot/pdfedit/pdfedit/src/xpdf/xpdf/PDFDoc.cc=2Cv
>> retrieving revision 1.6
>> diff -r1.6 PDFDoc.cc
>> 282d281
>> <   assert(!(secHdlr && !ret))=3B
>>
>> kernel tests on all of our test files run without crashing. michal=2C ca=
n you comment it out (at least)?
>
> PDFDoc.{cc=2Ch} is not maintained as I've already written in the off-list
> email so feel free to remove this.
> I would strongly discourage you from using this class though.

will commit it

>
>> it fails when executing one of our tests. It was not so easy as it
>> might seem to put it to this state :) next step would be to check the
>> results and improve them.
>
> Sorry=2C I don't get what you are trying to say.

i tried to say that there were several crashes on win32 when executing kern=
el tests on our test set.

>
>>
>> 2michal: would it be possible to have this check also on linux using
>> any (maybe already existing) script?
>
> Which check? Sorry=2C I don't understand.

do you run kernel tests on linux on the whole test suite with all tests ena=
bled?


>
>>
>> thx=2C
>> jozo
>
> --
> Michal Hocko
 		 	   		  =0A=
_________________________________________________________________=0A=
Hotmail: Trusted email with Microsoft=92s powerful SPAM protection.=0A=
http://clk.atdmt.com/GBL/go/177141664/direct/01/=

On Fri, Oct 09, 2009 at 05:23:56PM +0000, Jozef Misutka wrote:
> > On Fri=2C Oct 09=2C 2009 at 03:23:55PM +0000=2C Jozef Misutka wrote:
> >>
> >> hi=2C
> >>
> >> after removing
> >>
> >> RCS file: /cvsroot/pdfedit/pdfedit/src/xpdf/xpdf/PDFDoc.cc=2Cv
> >> retrieving revision 1.6
> >> diff -r1.6 PDFDoc.cc
> >> 282d281
> >> <   assert(!(secHdlr && !ret))=3B
> >>
> >> kernel tests on all of our test files run without crashing. michal=2C ca=
> n you comment it out (at least)?
> >
> > PDFDoc.{cc=2Ch} is not maintained as I've already written in the off-list
> > email so feel free to remove this.
> > I would strongly discourage you from using this class though.
> 
> will commit it
> 
> >
> >> it fails when executing one of our tests. It was not so easy as it
> >> might seem to put it to this state :) next step would be to check the
> >> results and improve them.
> >
> > Sorry=2C I don't get what you are trying to say.
> 
> i tried to say that there were several crashes on win32 when executing
> kernel tests on our test set.

Which tests with which files?

> 
> >
> >>
> >> 2michal: would it be possible to have this check also on linux using
> >> any (maybe already existing) script?
> >
> > Which check? Sorry=2C I don't understand.
> 
> do you run kernel tests on linux on the whole test suite with all tests ena=
> bled?

I usually run only those tests which might be affected by the code I am
changing. The whole test suite is rather time consuming for certain
documents (e.g. PDFReference16.pdf) and my laptop is practically
unusable during that time.

I cannot see any crash, though...

> 
> 
> >
> >>
> >> thx=2C
> >> jozo
> >
> > --
> > Michal Hocko
>  		 	   		  =0A=
> _________________________________________________________________=0A=
> Hotmail: Trusted email with Microsoft=92s powerful SPAM protection.=0A=
> http://clk.atdmt.com/GBL/go/177141664/direct/01/=

-- 
Michal Hocko

<20091011150850.GA6878@...>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0




----------------------------------------
> Date: Sun=2C 11 Oct 2009 17:08:50 +0200
> From: mstsxfx@...
> To: misutkajunior@...
> CC: pdfedit-devel@...
> Subject: Re: kernel unit tests
>
> On Fri=2C Oct 09=2C 2009 at 05:23:56PM +0000=2C Jozef Misutka wrote:
>>> On Fri=3D2C Oct 09=3D2C 2009 at 03:23:55PM +0000=3D2C Jozef Misutka wro=
te:
>>>>
>>>> hi=3D2C
>>>>
>>>> after removing
>>>>
>>>> RCS file: /cvsroot/pdfedit/pdfedit/src/xpdf/xpdf/PDFDoc.cc=3D2Cv
>>>> retrieving revision 1.6
>>>> diff -r1.6 PDFDoc.cc
>>>> 282d281
>>>> < assert(!(secHdlr && !ret))=3D3B
>>>>
>>>> kernel tests on all of our test files run without crashing. michal=3D2=
C ca=3D
>> n you comment it out (at least)?
>>>
>>> PDFDoc.{cc=3D2Ch} is not maintained as I've already written in the off-=
list
>>> email so feel free to remove this.
>>> I would strongly discourage you from using this class though.
>>
>> will commit it
>>
>>>
>>>> it fails when executing one of our tests. It was not so easy as it
>>>> might seem to put it to this state :) next step would be to check the
>>>> results and improve them.
>>>
>>> Sorry=3D2C I don't get what you are trying to say.
>>
>> i tried to say that there were several crashes on win32 when executing
>> kernel tests on our test set.
>
> Which tests with which files?
>
>>
>>>
>>>>
>>>> 2michal: would it be possible to have this check also on linux using
>>>> any (maybe already existing) script?
>>>
>>> Which check? Sorry=3D2C I don't understand.
>>
>> do you run kernel tests on linux on the whole test suite with all tests =
ena=3D
>> bled?
>
> I usually run only those tests which might be affected by the code I am
> changing. The whole test suite is rather time consuming for certain
> documents (e.g. PDFReference16.pdf) and my laptop is practically
> unusable during that time.
>
> I cannot see any crash=2C though...

that is good. now there are 2 types of errors shown by the cppunit library =
which we should eliminate somehow because they are not errors:

1. e.g. SLD-Intro.pdf

Run: 44 Failures: 0 Errors: 33
1) test: `anonymous namespace'::TestCContentStream::TestTm (E)=20
uncaught exception of type PermissionException=20
- Encryption credentials required

2. corrupted_bad_dictionary.pdf

1) test: `anonymous namespace'::TestCContentStream::TestTm (E)=20
uncaught exception of type PdfOpenException=20
- CPdf open failed. reason=3Dbad data stream


michal=2C do you have any idea how to make it in a clean way and easy to us=
e in future?

pdfreference is really time consuming but we can limit number of tested pag=
es to e.g. 50=2C what do you say?


/jozo



>
>>
>>
>>>
>>>>
>>>> thx=3D2C
>>>> jozo
>>>
>>> --
>>> Michal Hocko
>> =3D0A=3D
>> _________________________________________________________________=3D0A=
=3D
>> Hotmail: Trusted email with Microsoft=3D92s powerful SPAM protection.=3D=
0A=3D
>> http://clk.atdmt.com/GBL/go/177141664/direct/01/=3D
>
> --
> Michal Hocko
 		 	   		  =0A=
_________________________________________________________________=0A=
Hotmail: Free=2C trusted and rich email service.=0A=
http://clk.atdmt.com/GBL/go/171222984/direct/01/=

<COL111-W21ED6CB4C6470847F28B9AB6C80@...>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


and my current results (omitting pdfreference):

00uebung.pdf- OK (44 tests)=20

3_pkcs.pdf- OK (44 tests)=20

corrupted_bad_dictionary.pdf
- Run: 44 Failures: 0 Errors: 37=20

corrupted_bad_page.pdf
- Run: 44 Failures: 0 Errors: 37=20

corrupted_stream_content.pdf
- Run: 44 Failures: 0 Errors: 37=20

corrupted_stream_length.pdf
- Run: 44 Failures: 0 Errors: 37=20

corrupted_trailer.pdf
- Run: 44 Failures: 0 Errors: 37=20

corrupted_xref.pdf
- Run: 44 Failures: 0 Errors: 37=20

encrypt_nopasswd.pdf
- Run: 44 Failures: 0 Errors: 33=20

encrypt_passwd_a.pdf
- Run: 44 Failures: 1 Errors: 32=20

multiversion.pdf- OK (44 tests)=20

multi_enc.pdf
- Run: 44 Failures: 0 Errors: 37=20

SLD-Intro.pdf
- Run: 44 Failures: 0 Errors: 33=20

smallpdf.pdf- OK (44 tests)=20

TN5603.Filters.pdf
- Run: 44 Failures: 0 Errors: 37=20

zadani.pdf- OK (44 tests)

----------------------------------------
> From: misutkajunior@...
> To: mstsxfx@...
> Subject: RE: kernel unit tests
> Date: Mon=2C 12 Oct 2009 21:09:46 +0000
> CC: pdfedit-devel@...
>
>
> <20091011150850.GA6878@...>
> Content-Type: text/plain=3B charset=3D"iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> MIME-Version: 1.0
>
>
>
>
> ----------------------------------------
>> Date: Sun=3D2C 11 Oct 2009 17:08:50 +0200
>> From: mstsxfx@...
>> To: misutkajunior@...
>> CC: pdfedit-devel@...
>> Subject: Re: kernel unit tests
>>
>> On Fri=3D2C Oct 09=3D2C 2009 at 05:23:56PM +0000=3D2C Jozef Misutka wrot=
e:
>>>> On Fri=3D3D2C Oct 09=3D3D2C 2009 at 03:23:55PM +0000=3D3D2C Jozef Misu=
tka wro=3D
> te:
>>>>>
>>>>> hi=3D3D2C
>>>>>
>>>>> after removing
>>>>>
>>>>> RCS file: /cvsroot/pdfedit/pdfedit/src/xpdf/xpdf/PDFDoc.cc=3D3D2Cv
>>>>> retrieving revision 1.6
>>>>> diff -r1.6 PDFDoc.cc
>>>>> 282d281
>>>>> < assert(!(secHdlr && !ret))=3D3D3B
>>>>>
>>>>> kernel tests on all of our test files run without crashing. michal=3D=
3D2=3D
> C ca=3D3D
>>> n you comment it out (at least)?
>>>>
>>>> PDFDoc.{cc=3D3D2Ch} is not maintained as I've already written in the o=
ff-=3D
> list
>>>> email so feel free to remove this.
>>>> I would strongly discourage you from using this class though.
>>>
>>> will commit it
>>>
>>>>
>>>>> it fails when executing one of our tests. It was not so easy as it
>>>>> might seem to put it to this state :) next step would be to check the
>>>>> results and improve them.
>>>>
>>>> Sorry=3D3D2C I don't get what you are trying to say.
>>>
>>> i tried to say that there were several crashes on win32 when executing
>>> kernel tests on our test set.
>>
>> Which tests with which files?
>>
>>>
>>>>
>>>>>
>>>>> 2michal: would it be possible to have this check also on linux using
>>>>> any (maybe already existing) script?
>>>>
>>>> Which check? Sorry=3D3D2C I don't understand.
>>>
>>> do you run kernel tests on linux on the whole test suite with all tests=
 =3D
> ena=3D3D
>>> bled?
>>
>> I usually run only those tests which might be affected by the code I am
>> changing. The whole test suite is rather time consuming for certain
>> documents (e.g. PDFReference16.pdf) and my laptop is practically
>> unusable during that time.
>>
>> I cannot see any crash=3D2C though...
>
> that is good. now there are 2 types of errors shown by the cppunit librar=
y =3D
> which we should eliminate somehow because they are not errors:
>
> 1. e.g. SLD-Intro.pdf
>
> Run: 44 Failures: 0 Errors: 33
> 1) test: `anonymous namespace'::TestCContentStream::TestTm (E)=3D20
> uncaught exception of type PermissionException=3D20
> - Encryption credentials required
>
> 2. corrupted_bad_dictionary.pdf
>
> 1) test: `anonymous namespace'::TestCContentStream::TestTm (E)=3D20
> uncaught exception of type PdfOpenException=3D20
> - CPdf open failed. reason=3D3Dbad data stream
>
>
> michal=3D2C do you have any idea how to make it in a clean way and easy t=
o us=3D
> e in future?
>
> pdfreference is really time consuming but we can limit number of tested p=
ag=3D
> es to e.g. 50=3D2C what do you say?
>
>
> /jozo
>
>
>
>>
>>>
>>>
>>>>
>>>>>
>>>>> thx=3D3D2C
>>>>> jozo
>>>>
>>>> --
>>>> Michal Hocko
>>> =3D3D0A=3D3D
>>> _________________________________________________________________=3D3D0=
A=3D
> =3D3D
>>> Hotmail: Trusted email with Microsoft=3D3D92s powerful SPAM protection.=
=3D3D=3D
> 0A=3D3D
>>> http://clk.atdmt.com/GBL/go/177141664/direct/01/=3D3D
>>
>> --
>> Michal Hocko
> =3D0A=3D
> _________________________________________________________________=3D0A=3D
> Hotmail: Free=3D2C trusted and rich email service.=3D0A=3D
> http://clk.atdmt.com/GBL/go/171222984/direct/01/=3D
>
> -------------------------------------------------------------------------=
-----
> Come build with us! The BlackBerry(R) Developer Conference in SF=2C CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills=2C take BlackBerry mobile applications to market and st=
ay
> ahead of the curve. Join us from November 9 - 12=2C 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Pdfedit-devel mailing list
> Pdfedit-devel@...
> https://lists.sourceforge.net/lists/listinfo/pdfedit-devel
 		 	   		  =0A=
_________________________________________________________________=0A=
Hotmail: Free=2C trusted and rich email service.=0A=
http://clk.atdmt.com/GBL/go/171222984/direct/01/=

On Mon, Oct 12, 2009 at 09:09:46PM +0000, Jozef Misutka wrote:
> > On Fri=2C Oct 09=2C 2009 at 05:23:56PM +0000=2C Jozef Misutka wrote:
> >>> On Fri=3D2C Oct 09=3D2C 2009 at 03:23:55PM +0000=3D2C Jozef Misutka wro=
> te:
> >>>>
> >>>> hi=3D2C
> >>>>
> >>>> after removing
> >>>>
> >>>> RCS file: /cvsroot/pdfedit/pdfedit/src/xpdf/xpdf/PDFDoc.cc=3D2Cv
> >>>> retrieving revision 1.6
> >>>> diff -r1.6 PDFDoc.cc
> >>>> 282d281
> >>>> < assert(!(secHdlr && !ret))=3D3B
> >>>>
> >>>> kernel tests on all of our test files run without crashing. michal=3D2=
> C ca=3D
> >> n you comment it out (at least)?
> >>>
> >>> PDFDoc.{cc=3D2Ch} is not maintained as I've already written in the off-=
> list
> >>> email so feel free to remove this.
> >>> I would strongly discourage you from using this class though.
> >>
> >> will commit it
> >>
> >>>
> >>>> it fails when executing one of our tests. It was not so easy as it
> >>>> might seem to put it to this state :) next step would be to check the
> >>>> results and improve them.
> >>>
> >>> Sorry=3D2C I don't get what you are trying to say.
> >>
> >> i tried to say that there were several crashes on win32 when executing
> >> kernel tests on our test set.
> >
> > Which tests with which files?
> >
> >>
> >>>
> >>>>
> >>>> 2michal: would it be possible to have this check also on linux using
> >>>> any (maybe already existing) script?
> >>>
> >>> Which check? Sorry=3D2C I don't understand.
> >>
> >> do you run kernel tests on linux on the whole test suite with all tests =
> ena=3D
> >> bled?
> >
> > I usually run only those tests which might be affected by the code I am
> > changing. The whole test suite is rather time consuming for certain
> > documents (e.g. PDFReference16.pdf) and my laptop is practically
> > unusable during that time.
> >
> > I cannot see any crash=2C though...
> 
> that is good. now there are 2 types of errors shown by the cppunit library =
> which we should eliminate somehow because they are not errors:
> 
> 1. e.g. SLD-Intro.pdf
> 
> Run: 44 Failures: 0 Errors: 33
> 1) test: `anonymous namespace'::TestCContentStream::TestTm (E)=20
> uncaught exception of type PermissionException=20
> - Encryption credentials required
> 
> 2. corrupted_bad_dictionary.pdf
> 
> 1) test: `anonymous namespace'::TestCContentStream::TestTm (E)=20
> uncaught exception of type PdfOpenException=20
> - CPdf open failed. reason=3Dbad data stream
> 
> 
> michal=2C do you have any idea how to make it in a clean way and easy to us=
> e in future?

Each test has to check for conditions which make sense to it (encrypted?
linearized? read-only?). Some tests require read-write while read-only
is enough for others. I don't see any easy central way how to do that.

> 
> pdfreference is really time consuming but we can limit number of tested pag=
> es to e.g. 50=2C what do you say?

Page count limit sounds good, but I am afraid this would mean too many
changes all over tests because there is no central logic that. So I am
not sure whether it is worth effort.


-- 
Michal Hocko

On Mon, Oct 12, 2009 at 09:14:26PM +0000, Jozef Misutka wrote:
> 
>  <COL111-W21ED6CB4C6470847F28B9AB6C80@...>
> Content-Type: text/plain; charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> MIME-Version: 1.0
> 
> 
> and my current results (omitting pdfreference):
> 
> 00uebung.pdf- OK (44 tests)=20
> 
> 3_pkcs.pdf- OK (44 tests)=20
> 
> corrupted_bad_dictionary.pdf
> - Run: 44 Failures: 0 Errors: 37=20
> 
> corrupted_bad_page.pdf
> - Run: 44 Failures: 0 Errors: 37=20
> 
> corrupted_stream_content.pdf
> - Run: 44 Failures: 0 Errors: 37=20
> 
> corrupted_stream_length.pdf
> - Run: 44 Failures: 0 Errors: 37=20
> 
> corrupted_trailer.pdf
> - Run: 44 Failures: 0 Errors: 37=20
> 
> corrupted_xref.pdf
> - Run: 44 Failures: 0 Errors: 37=20

PDFOpenException not handled properly.

> 
> encrypt_nopasswd.pdf
> - Run: 44 Failures: 0 Errors: 33=20
> 
> encrypt_passwd_a.pdf
> - Run: 44 Failures: 1 Errors: 32=20

PermissionException not handled properly.

> 
> multiversion.pdf- OK (44 tests)=20
> 
> multi_enc.pdf
> - Run: 44 Failures: 0 Errors: 37=20

No Errors on my end.

> 
> SLD-Intro.pdf
> - Run: 44 Failures: 0 Errors: 33=20

PermissionException not handled properly.

> 
> smallpdf.pdf- OK (44 tests)=20
> 
> TN5603.Filters.pdf
> - Run: 44 Failures: 0 Errors: 37=20

No Errors for me.

> 
> zadani.pdf- OK (44 tests)
-- 
Michal Hocko