PDFedit Bugtracker
Main | My View | View Issues | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ View Advanced ] [ Issue History ] [ Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000328 [GUI] =Other (GUI)= major always 08-12-09 11:27 06-09-10 11:23
Reporter hockm0bm View Status public  
Assigned To bilbo
Priority high Resolution fixed  
Status resolved  
Summary 0000328: Discrepances when a text is added by GUI and kernel
Description It is yet some time when I have noticed that unexpected things are saved when changes in GUI are done. The issue is that also unchanged objects are marked as changed and so they are written into the file when document is saved.

Finally we have a simple way how to add a text without scripting so it is really easy to simulate the very same actions without GUI and scripting. Check the test case attached to (http://pdfedit.petricek.net/bt/view.php?id=303) [^] and use it on what-ever document (e.g. zadani.pdf). Let's call it zadani1.pdf

Then do the same in GUI (add text: "SOME TEXT TO ADD") to some position and save. Let's call it zadani2.pdf

The first thing you can notice is that zadani1.pdf has the following objects changed:
* [5 0] - page dictionary for the page because Contents changed to an array of 2 streams
* [21 0] - font dictionary which we have added along with text
* [26 0] - new content stream with added text

while zadani2.pdf contains:
* additional [6 0] - which is the original content stream. The only change I can see is that the original one had size in the indirect object while the changed one has direct value (orig: 2388 changed: 2383).

The change in size can be explained by different size of window for zlib compression and it is not important at this moment. What is more interesting is how and why this object got changed status.

I am not sure whether this is more GUI or kernel doing some tricks with indirect length value but it should be fixed.
Additional Information
Attached Files  fix_go_nosave.patch [^] (875 bytes) 05-12-10 14:19

- Relationships
related to 0000348resolved misuj1am PDFedit One character substituted for another in some pdf viewers after modifying a file with PDFedit. 

- Notes
(0000932)
hockm0bm
08-12-09 11:39

 I have tried to add something like this to the original test program:
        std::vector<boost::shared_ptr<CContentStream> > container;
        page->getContentStreams(container);
        std::string str;
        boost::shared_ptr<CContentStream> cs = *container.begin();
        cs->getStringRepresentation(str);
        std::cout<< str<<std::endl;

right before addSystemType1Font to force parsing of the original stream where the length could be potentially replaced to direct object but this had no influence.

So I think that this must be something GUI/scripting related.
 
(0001045)
hockm0bm
04-30-10 17:34

 Martin, could you have a look at http://pdfedit.petricek.net/bt/view.php?id=348 [^] and the explain why we call QSContentStream::saveChange on an unchanged object on the edit box keypress event?
 
(0001063)
hockm0bm
05-03-10 21:31

 Martin, bt#348 is already resolved so we should handle the GUI issue here.

Just as a reminder from bt#348:
* When you make a change to the page content (e.g. draw a line, add a text, etc...), the new content stream is created.

Let's add a simple text:
from QSPage::appendContentStream -> CPage -> CPageContents -> CPdf::addIndirectProperty -> XRefWriter -> CXref

* Page dictionary is updated to point to the new stream as well:
QSPage::appendContentStream -> CPage -> CPageContents::addToBack -> cc_add -> CPdf::changeIndirectObject -> CXref

* New system font is added
from QSPage::addSystemType1Font -> CPage -> CPageFonts -> CDict -> CPdf -> XRefWriter -> CXref

This is perfectly OK

* but then we have also the following trace which ends up in the CXref::changeObject which comes from GUI as an action from the
QLineEdit::returnPressed -> [...] -> QSContentStream::saveChange -> CContentStream::save -> CStream::setBuffer -> CDict::delProperty -> IProperty::dispatchChange -> CPdf -> CXref

So there seems to be a callback registered on the edit text box which is used for the text addition.

Do you have an idea why this happens?
 
(0001073)
hockm0bm
05-12-10 14:18

 OK, I have given it one more try:

Let's see what we are doing for text addition:

gui/dialogs.qs: connect( lineEdit, "returnPressed(const QString&)", _AddTextSlot );

This sets _AddTextSlot as a handler for the lineEdit which is the edit box which is used for text addition. So far so good.

_AdddTextSlot looks fine as well. Except it calls go() script which calls saveChage for all content streams on the page. This is how we get to changed content stream even though it wasn't touched at all.

This is very same for other operations on the page.
 
(0001074)
hockm0bm
05-12-10 14:19

 I have posted fix_go_nosave.patch to the devel list earlier today when I was fighting with other problem but it turned out to fix also this problem.
 
(0001083)
hockm0bm
05-25-10 13:59

 The patch has been committed to the CVS.
 
(0001087)
hockm0bm
06-09-10 11:23

 > The patch has been committed to the CVS.

Hmm, it seems that I forgot to commit it. It is there now, finally
 

- Issue History
Date Modified Username Field Change
08-12-09 11:27 hockm0bm New Issue
08-12-09 11:39 hockm0bm Note Added: 0000932
08-12-09 11:40 hockm0bm Status new => assigned
08-12-09 11:40 hockm0bm Assigned To  => bilbo
04-30-10 15:44 hockm0bm Relationship added related to 0000348
04-30-10 17:34 hockm0bm Note Added: 0001045
05-03-10 21:31 hockm0bm Note Added: 0001063
05-12-10 14:18 hockm0bm Note Added: 0001073
05-12-10 14:19 hockm0bm File Added: fix_go_nosave.patch
05-12-10 14:19 hockm0bm Note Added: 0001074
05-25-10 13:59 hockm0bm Status assigned => resolved
05-25-10 13:59 hockm0bm Resolution open => fixed
05-25-10 13:59 hockm0bm Note Added: 0001083
06-09-10 11:23 hockm0bm Note Added: 0001087