Git Log


Commit Date  
[ee8e8a] by Michal Hocko Michal Hocko

Test commit to find out if cvs log is delivered to the pdfedit-cvs mailing
list (After we had some problems on 23rd of Sept. 2008 when no meesage
was delivered).

2008-09-24 19:12:19 Tree
[59116b] by Michal Hocko Michal Hocko

*** empty log message ***

2008-09-23 22:57:13 Tree
[fa7443] by Michal Hocko Michal Hocko

From: mstsxfx@gmail.com
To: pdfedit-devel@lists.sourceforge.net
Subject: [PATCH @num@/@total@] FlateDecode encoder implementation

This patch implements FlatDecode (aka zlib) encode filter. This filter is
also set as default FilterStreamWriter.

Implementation (ZlibFilterStreamWriter) is based on libz (expects zlib-dev
package installed - TODO when pdfedit-dev is in the CVS to prevent
conflicts).

I have tested it with some basic content stream modification&save and
created stream was correctly formated FlateDecode stream readable by xpdf,
acrobat reader.

Current implementation uses default compression (no special predictor or
what-so-ever) so it doesn't need any additional parameters.

* xpdf code
- Object.{cc,h }
- initArray(Array*) added (I have used it for testing in the
beginning but then it turned out that I don't need it.
Nevertheless we have initDict(Dict*) so it is more
consistent to keep it. I will have no objections with
removing this hunk, though. Jozo?
- initName char* -> const char* (copyString is used inside,
so it is safe).
- Array.h, Dict.h
- getXRef method added because otherwise it is impossible to
create a new Array or dictionary
* pdfwriter
- ZlibFilterStreamWriter added (implements FlateDecode compression
algorithm)
- defaultWriter set to ZlibFilterStreamWriter

2008-09-23 22:39:27 Tree
[8a49fe] by Michal Hocko Michal Hocko

From: mstsxfx@gmail.com
To: pdfedit-devel@lists.sourceforge.net
Subject: [PATCH @num@/@total@] FilterStreamWriter introduction

This patch adds new FilterStreamWriter class which is responsible for proper
writing of stream objects. Currently we are writing streams in non
compressed form without any filters. This is far from ideal situation
because even simple change in the content stream may enlarge the final size
very rapidly.

FilterStreamWriter class is the first step to change this behavior. In the
first step we have simply created a class which provides interface for all
available filters (FilterStreamWriter) and current stream writing logic was
moved to the first implementation of filter stream writer named
NullFilterStreamWriter.

To provide easy-to-use and transparent interface we are using the following
hierarchy and class relations:
- FilterStreamWriter
- provides factory method getInstance which returns proper filter
writer instance based on the given stream object
- stream writers can be registered in runtime by
registerFilterStreamWriter method
- if getInstance is not able to find any suitable writer for a given
object, it will try default writer
- if even default doesn't support given object, it will fall back to
the NullFilterStreamWriter which writes raw data without any filters.

- default filter stream writer is useful for give-at-least some filter if
the required one is not available (e.g. LZWDecode can be replaced by
FlateDecode or stack of filters can be replaced by only one of them).

- each filter stream implementation is required to provide:
- supportObject - it understands how to write filtered data
specified by object.
- compress - write data from given object to the stream. Note that
this method can use different filters than specified in the
object, but it definitely has to write valid object (e.g. stack of
filters can be reduced or one filter can be replaced by another).

* FilterStreamWriter, NullFilterStreamWriter classes added
* writeObject
- updated to use FilterStreamWriter rather than direct code for
stream writing

Changelog v1 -> v2
==================
* design documentation updated

2008-09-23 22:36:47 Tree
[f63157] by Michal Hocko Michal Hocko

From: mstsxfx@gmail.com
To: pdfedit-devel@lists.sourceforge.net
Subject: [PATCH @num@/@total@] streamToCharBuffer refactored to enable encoders

This patch enhances streamToCharBuffer function to enable different data
extractors from a stream object. Original implementation contains data
extraction directly implemented in the function along with the logic how all
parts for the stream object should be put together in the result string.

However, if we want to implement stream writing with some other filters, we
have to duplicate much of this function. Therefore it is useful to make
stream data extraction transparent for streamToCharBuffer and deffer to the
extractor callback. Thus streamToCharBuffer can handle the rest (how to
write indirect header, dictionary, returned data stream and footer).

Original data extraction was moved to the bufferFromStreamData function
which is also used as default extractor.

Later extractors can be simply implemented in the following way:
unsigned char* foo_extractor(Object& obj, size_t& size)
{
unsigned char* rawBuffer;
size_t rawSize;
if((rawBuffer = bufferFromStreamData(obj, rawSize))==NULL)
goto ret;

// convert data according to the filter logic (may be stacked)
// add filters and their parameters to the dictionary
unsigned char * resultBuffer = foo_convert_data(rawBuffer, rawSize, size);
if(resultBuffer == NULL)
goto free_out;
update_dict(obj);
free_out:
free(rawBuffer);
return resultBuffer;
}

This implementation is a raw prototype (_no_ new functionality is implemented
so I don't expect any regressions - and my testing doesn't show any). I think
that following stuff should be changed (but I am not very sure how):
- move whole declaration stuff from cdict.h somewhere to the stream
related headers (where?)
- is the cobject2xpdf.cc proper place for implementation?
- naming is somehow awkward (streamToCharBuffer can be preserved)
- bufferFromStreamData uses allocated separate buffer from extractor
because it _cannot_ know in advance how much space extractor will
need. Therefore we have one allocation for each filter in the
extractor call stack. Ideally we could force extractor to place
data where bufferFromStreamData only reuses them without any
copying or allocation.
I would keep this as TODO to have the code easier at the moment
and work on this when we have everything in the CVS - to prevent
regressions.
Jozo, some ideas?

* stream_data_extractor function type added
* bufferFromStreamData added
- implementation of the stream_data_extractor extracted from
bufferFromStreamData
- removes all entries related to filters from stream dictionary
* bufferFromStreamData
- signature changed
- asIndirect removed - we don't need it ref==NULL is enough
- extractor added
- stream data extraction replaced by indirect call to extractor
- object::length is updated according to the extractor returned
buffer size
- default extractor is set to bufferFromStreamData

2008-09-23 22:34:07 Tree
[e28cd7] by Michal Hocko Michal Hocko

From: mstsxfx@gmail.com
To: pdfedit-devel@lists.sourceforge.net
Subject: [PATCH @num@/@total@] writeObject cleanup

OldstylePdfWrite currently uses two functions for writing objects:
- writeIndirectObject
- writeDirectObject
Their implementations are almost the same, thus a lot of code duplication.

This patch removes them and provides unified writeObject function which covers
both of them. Implementation is based on the writeIndirectObject and updated to
add indirect object specific stuff only if required by parameter.

streamToCharBuffer signature has to be updated too because we want to
prevent fake ref creation for direct object streams (btw. why is this
function in the cdict.h?).

* cdict.h, cobject2xpdf.cc
- streamToCharBuffer signature changed Ref -> Ref* (ignored if
asIndirect==false)
* pdfwriter.cc
- writeIndirectObject, writeDirectObject removed
- writeObject added

2008-09-23 22:21:11 Tree
[3231c9] by Michal Hocko Michal Hocko

updated from Georg Hofmann ([patch] pdfedit_de.ts - further small corrections)

2008-09-23 17:28:00 Tree
[3fc466] by Michal Hocko Michal Hocko

contributors updated

2008-09-22 16:50:57 Tree
[14385f] by Michal Hocko Michal Hocko

Update from Georg Hofman

2008-09-22 16:48:00 Tree
[907fbe] by Martin Petříček Martin Petříček

bug #247 fixed (default BG color is yellow)

2008-09-18 01:03:59 Tree
[58cfec] by Martin Petříček Martin Petříček

fixed changelog entry

2008-09-18 00:58:05 Tree
[19883e] by Martin Petříček Martin Petříček

fixed bug 258 (read-only exception not shown to user)

2008-09-18 00:52:59 Tree
[f42f38] by Martin Petříček Martin Petříček

#263 fixed

also, fixed passing of askPassword in basegui::loadPDF

2008-09-18 00:19:42 Tree
[f977e7] by Michal Hocko Michal Hocko

*** empty log message ***

2008-09-17 23:12:13 Tree
[d9c89c] by Martin Petříček Martin Petříček

cvsignore updated

2008-09-17 22:56:42 Tree
[8e5eaf] by Michal Hocko Michal Hocko

*** empty log message ***

2008-09-17 21:40:44 Tree
[f0dfbb] by Michal Hocko Michal Hocko

Delinearizator::delinearize declares that it returns either 0 on success or
errno on failure. Therefore we can't return -1 which doesn't stand for any
error.

* bad input parameters are treated as EINVAL
* no credentials as EPERM
* pdf header missing is announced as other corrupted data by
MalformedFormatExeption rather than error message
* Delinearizator::delinearize small doc update

2008-09-17 21:26:49 Tree
[53e11b] by Michal Hocko Michal Hocko

Close document if attempts to enter password fail

Allow opening documents without asking password from user
(could be used to implement password manager in script for example)
- user have to tamper with scripts to use this.

When encrypted document is opened, no more messagebox with warning is issued,
as we support them now Only notice to console and to the titlebar is written.

[Patch extracted from Martin's commit to the devel-msts-encrypted branch]

2008-09-17 21:22:45 Tree
[1a6df1] by Michal Hocko Michal Hocko

Asking for password implemented in places where it should be implemented

[Patch extracted from Martin's commit to the devel-msts-encrypted branch]

Dialog for asking password in the Base::delinearize code path for encrypted
documents. This however causes SEGV in the return path. Need to be
inspected.

2008-09-17 21:19:45 Tree
[bef7e7] by Michal Hocko Michal Hocko

added function to ask user for a password, invokable from scripting interface

[Patch extracted from Martin's commit to the devel-msts-encrypted branch]

2008-09-17 21:18:13 Tree
[dba980] by Michal Hocko Michal Hocko

New test module (testencrypt.cc) for encrypted documents testing is added by
this patch.

Unlike other test modules checks only those files which are specified in the
configuration file because this file provides also access credentials which are
necessary for proper testing.

Configuration file can be specified by -passwd_rc parameter or
encrypt_passwd.rc is used by default.

* testencrypt.cc
- checks only files from configuration file (ignores all
files from command line).
- tests for credentials available case (either bad or good from
conf. file)

* encrypt_passwd.rc file holds default configuration for encrypted
documents. This means file with following format:

file_name:passwd

on each line for all documents which should be tested. If password is empty,
simple `:' at the end of line should be used. No trailing/leading spaces
are skipped.

* testmain.cc
- new parameter to the test binary (-passwd_rc) which overwrites
default configuration file.
- TestParams::init - instance() replaced by params initialized from
instance() for better readability

2008-09-17 21:12:51 Tree
[109ffa] by Michal Hocko Michal Hocko

This patch introduces checks for credentials required for encrypted
document (test is done by check_need_credentials function which throws
PermissionException if they are not provided).

* initRevisionSpecific is postponed for encrypted documents until
setCredentials is called
* needsCredentials, setCredentials methods added
* check_need_credentials used where credentials a required
- getOutlines, getIndirectProperty, addIndirectProperty,
changeIndirectProperty, getPage, getPageCount, getPagePosition,
insertPage, removePage, canChange
* changeIndirectProperty throws NotImplementedException if document is
encrypted and doesn't rely on XRefWriter::changeObject to throw because we
would need to cach and do a clean up in such a case

2008-09-17 21:10:37 Tree
[a5c0d7] by Michal Hocko Michal Hocko

Encryption credentials checking and setting code was extracted from PDFDoc
to utils functions to enable reusing them.
SecurityHandler needs some changes to be reused by our code, because it
is bound to PDFDoc class too tightly. I have replaced it by XRef but
this means that security plugins are _not_ possible at the moment.
ExternalSecurityHandler uses some stuff from PDFdoc.

* compiler should emit error if ENABLE_PLUGINS is configured because
this means that ExternalSecurityHandler is compiled and it depends on
PDFDoc. This should not be any problem for our usage, because we have
never compiled with ENABLE_PLUGINS AFAIK.
* PDFDoc removed from SecurityHandler
* constructors gets XRef * rather than PDFDoc *
* getAuthData doesn't call gui method to get credentials we will only
use provided one. Simply returns NULL.
* checkEncryption, setEncryptionCred added
- function is extracted from PDFDoc::checkEncryption
* Makefile.in
- encrypt_utils.{cc,o} added

2008-09-17 21:03:36 Tree
[329358] by Michal Hocko Michal Hocko

utils::isEncrypted function signature and implementation change with
sync of all users

* isEncrypted
- filter parameter removed - it is not checked anymore
- don't check encryption dictionary directly and rather asks
underlaying xref (isEncrypted method)

2008-09-17 20:58:43 Tree
[95a19a] by Michal Hocko Michal Hocko

Support for encrypted documents implementated for XRefWriter

* checkLinearized
- gets CXref* rahter than Xref* parameter because we have to call
check_need_credentials here. We can't check unknown document content
without encryption credentials.
- doesn't check for credentials because we want to use it in no throw
context and it is helper, so it is ok to rely on caller

* XRefWriter::XRefWriter
- checkLinearized and collectRevisions is called even for encrypted
documents because we are not reading encrypted data in that path
- note that we have to be in internal_fetch mode for
collectRevisions method because fetch would throw exception
otherwise (because of missing credentials)

* setCredentials method added - TODO really needed?
- delegates to CXref implementation

* changeObject, changeTrailer, createObject, cloneRevision throws
NotImplementedException if document is encrypted. We are not able to encrypt
changed content and we would get invalid document (after save) without that.

* changeRevision
- checks check_need_credentials

2008-09-17 20:56:25 Tree
Older >

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks