Another bug in m92 1.7 20120726 - serious. - Page 3

thorgal · 08-17-2012, 06:14 PM

Thanks. I´ll better dont take risks and leave it alone for now since it is not a problem anymore. BTW it seems what both issues (the merging one and the mine) are related. Obviously the new beta reader has messed it all somehow.

Knorke · 08-19-2012, 04:54 AM

Quote:

Originally Posted by thorgal

...Obviously the new beta reader has messed it all somehow.

The merging problem does also occure with the older pdf reader, not only the beta version. So I'm not sure if the two problems are really related.

Can anybody say something to my observation with the special characters, please? I still no know if it is a problem of my device/software or a general one.

Thanks!

janek · 08-19-2012, 11:54 AM

Quote:

Originally Posted by Knorke

The merging problem does also occure with the older pdf reader, not only the beta version. So I'm not sure if the two problems are really related.

Can anybody say something to my observation with the special characters, please? I still no know if it is a problem of my device/software or a general one.

Thanks!

Yes, I fully confirm your findings with regard to 1.7 20120726, old reader. Some characters in comments make merging annotations impossible. After their removal, merging annotations is possible again. And this is something different than the bug I reported, which is unrelated to pdf/comment contents. So we have two ugly bugs related to exporting annotations, not just one - hope they get triaged and eventually fixed very soon.

Knorke · 08-22-2012, 03:25 AM

The (old) pdf reader seems to be full of bugs. At the moment I've observed the following:

1) Annotation: Merging does not work when special characters are used in the comment text (see the discussion above)

2) To many comments per page slow down the working speed of the M92 (only for the page with the many comments)

3) The combination of pictures and text can slow down the working speed of the M92 dramatically (possibly related to bug 2?)

4) In some pdf documents the space characters are are not adopted in the comment text (thetextisnotreallyreadable)

Additionally we have still the problem of janek

Im really frustrated at the moment. Problem 1) I can avoid until the bug is fixed. Because of the others it's not possible to WORK with pdf files for me. But this (working with pdf files) is the core feature of the device. As long we have this beta status the sellers should not advertise with this core feature in my opinion! The potential of the device is high - no question. But at the moment it's not more than a (frustrating) toy.

I try to examine the bugs 2-4 to locate the reason. Than I'll try to generate public test files.

If you've observed similiar or other bugs concering pdf reader please let me know.

Thanks.

janek · 08-22-2012, 04:11 AM

Quote:

Originally Posted by Knorke

The (old) pdf reader seems to be full of bugs. At the moment I've observed the following:

1) Annotation: Merging does not work when special characters are used in the comment text (see the discussion above)

2) To many comments per page slow down the working speed of the M92 (only for the page with the many comments)

3) The combination of pictures and text can slow down the working speed of the M92 dramatically (possibly related to bug 2?)

4) In some pdf documents the space characters are are not adopted in the comment text (thetextisnotreallyreadable)

Additionally we have still the problem of janek

Bug 4 has been know for a while and it is not really Onyx's fault. It is also unrelated to the merging functions. Some PDFs have the text layer (the actual text under the scanned page) merged with the scanned images in such a way that individual words are allocated to individual places under the scanned image, respective to single words in it, rather than to entire line or entire block of text. In this way the layout of the scanned page is closely replicated by "actual" text - individual words in the text layer match individual words in image layer.
Now the thing is that in such a case there may be no spaces in the text layer, but naboo_reader (the old pdf reader build on Adobe SDK) does not know about that (hence copied/marked text contains no spaces). Which is (as Booxtor says) caused by a bug in closed-source Adobe SDK and so cannot be fixed by Onyx.

There is also bug 5 (or bug 4 proper) - sometimes some annotations are not merged, even if the output file is produced. I experienced that and there's report of this behaviour in the Polish forum, so it is confirmed.

Knorke · 08-22-2012, 04:54 AM

Quote:

Originally Posted by janek

Bug 4 has been know for a while and it is not really Onyx's fault. It is also unrelated to the merging functions. Some PDFs have the text layer (the actual text under the scanned page) merged with the scanned images ...

Thanks for the helpful comments. In the two cases with bug 4 (missings space) the pdf files are not scanned. They are generated by pdflatex+Adobe destiller or Elsevier.

When I mark the text with the Adobe pdf reader and copy it to an editor the spaces are correct.

Than I took a scanned patent pdf, used the Acrobat OCR and - hold your hat - the onyx detects the spaces correctly!

--> In my case the space problem does not correlate with scanned or not scanned file!

janek · 08-22-2012, 06:36 AM

Quote:

Originally Posted by Knorke

Thanks for the helpful comments. In the two cases with bug 4 (missings space) the pdf files are not scanned. They are generated by pdflatex+Adobe destiller or Elsevier.

When I mark the text with the Adobe pdf reader and copy it to an editor the spaces are correct.

Than I took a scanned patent pdf, used the Acrobat OCR and - hold your hat - the onyx detects the spaces correctly!

--> In my case the space problem does not correlate with scanned or not scanned file!

Bizarre indeed. One small correction: what I wanted to say is not that every scanned/ocr-ed document causes such problems neither that no "generated" ones do, but that the bug is related to how how text layer is organized.
I'm able to reproduce this behaviour by using linux utility called gscan2pdf to scan and ocr documents.

Knorke · 08-22-2012, 11:12 AM

Quote:

Originally Posted by janek

...how text layer is organized...

Does someone knows a tool to examine the layer structure of a pdf document?

Knorke · 10-22-2012, 03:35 AM

Hello Booxtor, hello users.

Introduction
Based on my posting #34 in this thread I've tried to examine some annotation problems with pdf files. I've found a nice pdf document produced by pdfTeX/LaTeX in the web. It has pages without graphic, with vector graphics and with bitmap graphics.

All 3 bugs (number 2-4 in my posting #34) occur in this file. All 3 kinds of bugs (and the known bug 1) I've in nearly every journal paper I want to read and annotate. On a new page without comments the response times are normal.

Short explanation of the 'experiment'
I made a lot of annotations on 4 typical pages and recorded the response time

The original file you can find here:

http://tex.aanhet.net/rugtex/figlatex.pdf

The results of my (frustrating) tests you can find here:
http://dl.dropbox.com/u/97906838/pdf...ons_Knorke.pdf

Meaning of the colums in the result file:
comment number - number of the comment (per page)
selection time - response time when I change the selected text by moving the pen
menu appear. - time after which the text input menue appears
menue dissappear. - time after which the menu disappears after pressing 'OK'
editing time sum - sum of the three response times / time for one comment

Results
Also without graphics the response time increases very quickly. In the case of my test file on page 6 comment nr. 74 takes in sum 15 seconds without adding any text. This seems to be a problem of the database of the M92.

If you have graphics you really get in hot water. Especialliy the response time when you select the text can be more than one minute! Colleagues laught at me when they observed my long persistance to mark some words. This time grows not directly with the comment number. Between long times there are comments with shorter response times. The time of the appearance and disappearance of the text menu increases continuously with the comment number. With the test file page 2 is very frustrating (have a look at the result file).

Summary
Booxtor and Onyx, please fix this bugs. Your are so close to the destination. But at the moment working with the M92 is very very frustrating. And please don't tell me it's because of the poor Adobe SDK.

Mono · 10-23-2012, 04:45 PM

Interesting. If I look at your measurements I see that for minimaly 7 notes on page it works quite fine. For some types of test pages even much more notes per page.

It looks like it was tested and designed for reasonably expectable number of notes per page, say something like sub 8.

Do you really think that significant number of users would make more than 8 notes per page?

I wouldn't. But there might be a large group of users who need make 8+ notes per page. I do not know.

Do you or person you know really need 8+ notes per page?

I do not say, this should not be improved/"fixed", but it seems to me that there are more important issues. But that is my point of view and your's might be quite different...

Knorke · 10-24-2012, 04:22 AM

Quote:

Originally Posted by Mono

...

It looks like it was tested and designed for reasonably expectable number of notes per page, say something like sub 8.
...

Thanks for your comment!

I can you show documents/pages where only 1 or 2 comments work fine and after that you need about 1 minute per annotate. 70 comments per page are not realistic, I agree. But with nearly every pdf (journal paper) I read and annotate the shown behaviour disturbs the workflow. There I have < 10 comments per page. Especially the random appearence of is very frustrating when you have to wait more than 1 minute that something happens.

Mono · 10-24-2012, 06:21 AM

OK, I do not use this functionality, so I do not know how it behaves in real life.

If it is like you say, something should be done. As it depends on type of graphics on page, it might be related to Adobe SDK. The page has to be rendered and different pages might consume different amount of RAM. When anotation is invoked and there is more than certain amount of RAM needed for the task, swaping of RAM to "disk" must be done. It takes time.... And two processes might run and "compete" for RAM and inforce massive swapping of RAM there and forth. It could be something like this, but of course it is only my wild guess.

Maybe that a new pdf reader will behave better....

Booxtor · 10-24-2012, 01:26 PM

This behavior is definitely caused by adobe sdk. You won't believe how many odd bugs it still contains. Some of could be fixed, some are hard to skirt.
I have tested your file with new PDFreader and can confirm some issues are still there (missingspaceproblem and slowdown of going to next page by particular high number of annotations per page). öäüß problem has been already solved. Our best adobe specialist is trying to fix the other issues now.

Mono · 10-24-2012, 04:24 PM

I believe you that Adobe SDK may have many odd bugs.

The odd bug in Microsoft runtime library cost me several days of my time. Fortunately, source code for that library was at hand and I could fix it myself... But I was close to kill Bill.

Knorke · 10-25-2012, 04:23 AM

Quote:

Originally Posted by Booxtor

This behavior is definitely caused by adobe sdk. ...

Sorry for my provocative comment in my posting concering the Adobe sdk. Thanks a lot for your reply and support.

10-22-2012, 03:35 AM	#39
Knorke Enthusiast Posts: 33 Karma: 66 Join Date: Aug 2012 Device: Onyx Boox M92	Phenomenological examination of annotation problems Hello Booxtor, hello users. Introduction Based on my posting #34 in this thread I've tried to examine some annotation problems with pdf files. I've found a nice pdf document produced by pdfTeX/LaTeX in the web. It has pages without graphic, with vector graphics and with bitmap graphics. All 3 bugs (number 2-4 in my posting #34) occur in this file. All 3 kinds of bugs (and the known bug 1) I've in nearly every journal paper I want to read and annotate. On a new page without comments the response times are normal. Short explanation of the 'experiment' I made a lot of annotations on 4 typical pages and recorded the response time The original file you can find here: http://tex.aanhet.net/rugtex/figlatex.pdf The results of my (frustrating) tests you can find here: http://dl.dropbox.com/u/97906838/pdf...ons_Knorke.pdf Meaning of the colums in the result file: comment number - number of the comment (per page) selection time - response time when I change the selected text by moving the pen menu appear. - time after which the text input menue appears menue dissappear. - time after which the menu disappears after pressing 'OK' editing time sum - sum of the three response times / time for one comment Results Also without graphics the response time increases very quickly. In the case of my test file on page 6 comment nr. 74 takes in sum 15 seconds without adding any text. This seems to be a problem of the database of the M92. If you have graphics you really get in hot water. Especialliy the response time when you select the text can be more than one minute! Colleagues laught at me when they observed my long persistance to mark some words. This time grows not directly with the comment number. Between long times there are comments with shorter response times. The time of the appearance and disappearance of the text menu increases continuously with the comment number. With the test file page 2 is very frustrating (have a look at the result file). Summary Booxtor and Onyx, please fix this bugs. Your are so close to the destination. But at the moment working with the M92 is very very frustrating. And please don't tell me it's because of the poor Adobe SDK. Last edited by Knorke; 10-23-2012 at 01:57 AM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Bug: M92 - Annotations in PDF disappearing!	Defenderland	Onyx Boox	15	05-11-2013 03:35 PM
M92 scribling bug?	Mono	Onyx Boox	2	03-08-2012 07:33 PM
Boox M92. Spring Bargains. The price of M92 stays reduced for 14 days :)	Booxtor	Onyx Boox	5	03-02-2012 05:16 AM
Embedded font bug or CSS bug in ADE	JSWolf	ePub	10	06-11-2011 02:34 PM
PRS-505 bug or eBookLib bug?	porkupan	Sony Reader	3	10-07-2007 10:44 PM

08-17-2012, 06:14 PM	#31
thorgal Member Posts: 22 Karma: 10 Join Date: Feb 2012 Device: Hanlin V3, Onyx M92	Thanks. I´ll better dont take risks and leave it alone for now since it is not a problem anymore. BTW it seems what both issues (the merging one and the mine) are related. Obviously the new beta reader has messed it all somehow.

08-22-2012, 03:25 AM	#34
Knorke Enthusiast Posts: 33 Karma: 66 Join Date: Aug 2012 Device: Onyx Boox M92	More bugs in the pdf reader The (old) pdf reader seems to be full of bugs. At the moment I've observed the following: 1) Annotation: Merging does not work when special characters are used in the comment text (see the discussion above) 2) To many comments per page slow down the working speed of the M92 (only for the page with the many comments) 3) The combination of pictures and text can slow down the working speed of the M92 dramatically (possibly related to bug 2?) 4) In some pdf documents the space characters are are not adopted in the comment text (thetextisnotreallyreadable) Additionally we have still the problem of janek Im really frustrated at the moment. Problem 1) I can avoid until the bug is fixed. Because of the others it's not possible to WORK with pdf files for me. But this (working with pdf files) is the core feature of the device. As long we have this beta status the sellers should not advertise with this core feature in my opinion! The potential of the device is high - no question. But at the moment it's not more than a (frustrating) toy. I try to examine the bugs 2-4 to locate the reason. Than I'll try to generate public test files. If you've observed similiar or other bugs concering pdf reader please let me know. Thanks.

10-23-2012, 04:45 PM	#40
Mono Mono Posts: 699 Karma: 13333 Join Date: Jan 2012 Device: Boox M92	Interesting. If I look at your measurements I see that for minimaly 7 notes on page it works quite fine. For some types of test pages even much more notes per page. It looks like it was tested and designed for reasonably expectable number of notes per page, say something like sub 8. Do you really think that significant number of users would make more than 8 notes per page? I wouldn't. But there might be a large group of users who need make 8+ notes per page. I do not know. Do you or person you know really need 8+ notes per page? I do not say, this should not be improved/"fixed", but it seems to me that there are more important issues. But that is my point of view and your's might be quite different...

10-24-2012, 06:21 AM	#42
Mono Mono Posts: 699 Karma: 13333 Join Date: Jan 2012 Device: Boox M92	OK, I do not use this functionality, so I do not know how it behaves in real life. If it is like you say, something should be done. As it depends on type of graphics on page, it might be related to Adobe SDK. The page has to be rendered and different pages might consume different amount of RAM. When anotation is invoked and there is more than certain amount of RAM needed for the task, swaping of RAM to "disk" must be done. It takes time.... And two processes might run and "compete" for RAM and inforce massive swapping of RAM there and forth. It could be something like this, but of course it is only my wild guess. Maybe that a new pdf reader will behave better....

10-24-2012, 01:26 PM	#43
Booxtor Booxtor Posts: 1,126 Karma: 2305664 Join Date: Jun 2011 Location: Germany Device: a lot of..	This behavior is definitely caused by adobe sdk. You won't believe how many odd bugs it still contains. Some of could be fixed, some are hard to skirt. I have tested your file with new PDFreader and can confirm some issues are still there (missingspaceproblem and slowdown of going to next page by particular high number of annotations per page). öäüß problem has been already solved. Our best adobe specialist is trying to fix the other issues now.

10-24-2012, 04:24 PM	#44
Mono Mono Posts: 699 Karma: 13333 Join Date: Jan 2012 Device: Boox M92	I believe you that Adobe SDK may have many odd bugs. The odd bug in Microsoft runtime library cost me several days of my time. Fortunately, source code for that library was at hand and I could fix it myself... But I was close to kill Bill.