Art Olin | 20 Apr 2011 21:10
Picon
Favicon

miscellaneous pdfedit issues

Hi, Michal.

When I use the addText gui button to insert new test into a document, I 
find that successive insertions require exponentially greater time to 
execute. During this period the gui is frozen and the code consuming 
100% cpu but modest memory. After three or four insertions the time to 
add additional characters will be 10s of minutes. The length of the 
added strings seem to be irrelevant. After repeated additions the 
process of saving the file on exiting the gui is quite long. When you 
save a revision and exit the gui, subsequent text additions start 
quickly and increase in time as before.

I would like to be able to add annotations to documents, and this is not 
fully supported in the gui. I've found that I can instantiate an 
annotation from the command line with
addAnnotation(firstSelected(), p1, p2, l, h) after selecting a page with 
the cursor. The annotation appears
when the gui "select annotations" is set, but the content is not 
visible, and when I select the annotation
I get an error:QString::arg(): Argument missing: 
go_to_target_from_selected_annotation(), 0). Clearly some links are missing.

Is there a simple script to generate editable annotations?

Finally, when i do gui select text and select some, it appears in a 
little window of the gui and can be edited. As soon as you change 
anything, all the spaces disappear, and if spaces are added manually 
they do not appear on the pdf. Is there a workaround for this.

  I'm using the latest code downloaded from the ubuntu rep.
(Continue reading)

Michal Hocko | 21 Apr 2011 16:30
Picon

Re: miscellaneous pdfedit issues

On Wed, Apr 20, 2011 at 12:10:24PM -0700, Art Olin wrote:
> Hi, Michal.

Hi,

> 
> When I use the addText gui button to insert new test into a document, I 
> find that successive insertions require exponentially greater time to 
> execute. During this period the gui is frozen and the code consuming 
> 100% cpu but modest memory. After three or four insertions the time to 
> add additional characters will be 10s of minutes. The length of the 
> added strings seem to be irrelevant. After repeated additions the 
> process of saving the file on exiting the gui is quite long. When you 
> save a revision and exit the gui, subsequent text additions start 
> quickly and increase in time as before.

Yes, this is a known issue and I guess it is reported in our bug
tracking system (http://pdfedit.petricek.net/bt/main_page.php) as well.
I am not an author of GUI so my knowledge of this area is very limited.
I was told that the problem is in the QSA scripting layer which leaks
memory a lot. The only proposed "solution" was to get rid of QSA and
move to qscript in the QT4 base port. I am not sure what is the current
status of that, though. Maybe Martin can tell us more.

> 
> I would like to be able to add annotations to documents, and this is not 
> fully supported in the gui. I've found that I can instantiate an 
> annotation from the command line with
> addAnnotation(firstSelected(), p1, p2, l, h) after selecting a page with 
> the cursor. The annotation appears
(Continue reading)

Art Olin | 21 Apr 2011 17:35
Picon
Favicon

Re: miscellaneous pdfedit issues

On 11-04-21 07:30 AM, Michal Hocko wrote:
> On Wed, Apr 20, 2011 at 12:10:24PM -0700, Art Olin wrote:
>> Hi, Michal.
> Hi,
>
>> When I use the addText gui button to insert new test into a document, I
>> find that successive insertions require exponentially greater time to
>> execute. During this period the gui is frozen and the code consuming
>> 100% cpu but modest memory. After three or four insertions the time to
>> add additional characters will be 10s of minutes. The length of the
>> added strings seem to be irrelevant. After repeated additions the
>> process of saving the file on exiting the gui is quite long. When you
>> save a revision and exit the gui, subsequent text additions start
>> quickly and increase in time as before.
> Yes, this is a known issue and I guess it is reported in our bug
> tracking system (http://pdfedit.petricek.net/bt/main_page.php) as well.
> I am not an author of GUI so my knowledge of this area is very limited.
> I was told that the problem is in the QSA scripting layer which leaks
> memory a lot. The only proposed "solution" was to get rid of QSA and
> move to qscript in the QT4 base port. I am not sure what is the current
> status of that, though. Maybe Martin can tell us more.
>
> Thanks, Michal. I expect that the QT4 port will fix many of these performance problems.
>> I would like to be able to add annotations to documents, and this is not
>> fully supported in the gui. I've found that I can instantiate an
>> annotation from the command line with
>> addAnnotation(firstSelected(), p1, p2, l, h) after selecting a page with
>> the cursor. The annotation appears
>> when the gui "select annotations" is set, but the content is not
>> visible, and when I select the annotation
(Continue reading)

Michal Hocko | 22 Apr 2011 10:47
Picon

Re: miscellaneous pdfedit issues

On Thu, Apr 21, 2011 at 08:35:08AM -0700, Art Olin wrote:
> For the text editing, I am asking for a rather small change - that the 
> text be restored with its original formatting, 

This is not that small change as it might look like. What GUI actually
does is that it gets all selected operators (PDF creator can decide
to wrap every single character into a separate operator prefixed with
placement oprators so word boundaries are hard to find out without
evaluating those operators as well) and gets the text out of it. The it
shows the text.  If you change the text it will simply create a new text
operator which contains whole text. Yes, very simplistic approach. The
real implementation should create a new formatting.

> and that users are informed of the proper space character to enable   
> this formatting in added text. At present you basically select a line 
> and the formatting, especially spaces between the words, disappears.  

As already said above, GUI is not considering placement operators.
We have an extract text functionality so the code could be reused but I
do not know how much work it would be.

> Surely this can be improved, and it is separate from QT4. Sorry
> I can't help with it.  

Last discussion we had with Jozef and Martin ended up with a conclusion
that the current GUI design is terribly heavy weight and the new QT4
code should be much simpler. But it seems that nobody has time to
implement it. I am basically in the maintenance mode trying to fix bugs
and backport xpdf security fixes - but I do not have much time to work
on new features. I hope that somebody takes the core library and build a
(Continue reading)


Gmane