Another bug in m92 1.7 20120726 - serious.

[Knorke]

Originally Posted by janek

...

Anyway, one of the files that failed to merge is this

...

It is possible this is yet another bug. I don't use German umlauts in my annotations nor greek letters. I do use non-kosher characters (Polish), but in many files where I use them, I'm still able to merge annotations.

Hi janek, hi Booxtor

I took a look on your pdf document. It's very easy to provoke the bug. Please mark the name "Hákan Hydén" on page 26 (line 7) with an annotation and press ok to use the marked text as annotation content. With my M92 it's enough to avoid the merging.

When I note other parts of the text the merging works fine. So att the moment I still belive in special signs as "trigger" for the bug.

Please let me know if you can reproduce my observation or if it's a problem with my device/software configuration.

Thanks!

[Knorke]

Additionally I've created a pdf-testfile with Libre Office to investigate my assumption with special signs. Sorry for the german language in the document. The first file is the original Libre Office pdf.

The second one is generated by the M92. I marked the special signs in every line and tried to merge the pdf file (I've tried to create about 30 pdf files by merging). For the non marked lines it was not possible to merge the file. So you can see which characters provoke the bug. For the last block with the single characters I lost one's patience.

Original file:
pdf-Test-Dokument_Nr_2.pdf

File created by the M92:
pdf-Test-Dokument_Nr_2_2012-8-13_22-29-42.pdf

Another (small) bug is obvious: Sometimes the marked area does not coincide with the recorded text.

Perhaps it helps to solve the problem - my job as beta tester is done for today

[janek]

Originally Posted by Knorke

Additionally I've created a pdf-testfile with Libre Office to investigate my assumption with special signs. Sorry for the german language in the document. The first file is the original Libre Office pdf.

The second one is generated by the M92. I marked the special signs in every line and tried to merge the pdf file (I've tried to create about 30 pdf files by merging). For the non marked lines it was not possible to merge the file. So you can see which characters provoke the bug. For the last block with the single characters I lost one's patience.

Original file:
pdf-Test-Dokument_Nr_2.pdf

File created by the M92:
pdf-Test-Dokument_Nr_2_2012-8-13_22-29-42.pdf

Another (small) bug is obvious: Sometimes the marked area does not coincide with the recorded text.

Perhaps it helps to solve the problem - my job as beta tester is done for today

Thx for your testing. For some reason I'm unable to download the file you posted, but still I can't confirm that in my case special characters indeed spark the problem. I've checked my annotations and annotated fragments, and there's no umlauts there. Even upon removing all non-ascii characters from annotations (such as Polish special characters ąęśćżźńółĄĘŚĆŻŹŃÓŁ) and deleting annotations where text contains such characters, the situation is not changed. Also, umlauts do not explain erratic behaviour with edited *.sketch files (see my earlier post).
So it looks like we have two bugs here.

To be sure, please tell me Knorke: if you mark an "unmergeable" umlaut, and then remove the annotation, can you merge other annotations? In my case deleting annotations does not help.

[Knorke]

Originally Posted by janek

To be sure, please tell me Knorke: if you mark an "unmergeable" umlaut, and then remove the annotation, can you merge other annotations? In my case deleting annotations does not help.

Yes, in 100% of my tests the removing of "bad comments" leads to a mergable file.

At this time the following characters produce reproducable problems in the comment text with my device and firmware:

ö ä ü ß µ § ´ å é

[Edit] New finding: The critical point is not the marked text with special characters but only the comment text! So you can mark for instance "120 µm" in your pdf, change the comment text to "120 mue" or put the space character (deleting with the M92 does not work) and merging ist possible.

[Etoja]

They have obviously messed up the firmware (1.7 (1.7.20120726) - after updating I can't see many languages in the Languages Icon in the settings, there are only empty squares and no name of the corresponding language in the selection dropdown list. Though English and German, as well as Chinese and Corean and some other languages, are present. No Russian.
Some file names are seen as the extentions only, I can't say if they are Cyrillic fonts, no way to check because the device is frozen at the moment.

I have updated it one day ago, and was reading with no problems until this morning - it got frozen while opening my book I was reading - it shows the book page and nothing happens, reset doesn't help. I'm trying to charge the battery to full, as somebody suggested, but not sure if it helps - can it be related to the firmware update?

[Etoja]

P.S. Some time later... I have just managed to unfreeze Onyx 92 by pushing reset and pressing the switch button. It works now.

[PitchIt]

Originally Posted by janek

In 1.7 20120726 merging scribbles and annotations with pdf works erratically. Sometimes it works as normal but sometimes it does not work at all - no output file is produced! It also happened to me that an output file was produced but no scribbles/annotations were merged with it. I tested this with a dozen files I have on my reader and that I had annotated previously to find that about one fifth of them is affected. Exporting annotations to text file does not seem to be affected.

Now, the strangest bit is that the same file, uploaded fresh to m92 with a new file name and annotated anew, can be succesfully merged!
On the other hand, if the filename of the affected document is changed and then the same file with old name is re-uploaded to the device, annotations and scribbles can be seen in the newly uploaded file (they are lost in the old one*) but still cannot be merged.
It follows from this that the bug is related to boox, not to the annotated file.

Since I can't figure what is causing this (database failure? bug in software?) it means annotations/scribbles cannot be relied on anymore. It's probably not just me that they only make sense if they can be transferred to PC. This is really upsetting.

* Changing the file name of an annotated document makes annotations and scribbles disappear - they cannot be seen anymore in the document with a changed name. If the file name is changed back to the original one, annotations and scribbles reappear. I consider this a bug, too.

This is a most important problem for me since merging of annotations has been a mayor reason for me to buy the reader. Please, fix :0)

[thorgal]

I am suffering another annoying bug related with the beta PDF reader: Any PDF document opened with it cannot be opened with the old reader anymore. Is there some place where the reader saves its temporary files in order to delete them?

[janek]

Originally Posted by thorgal

I am suffering another annoying bug related with the beta PDF reader: Any PDF document opened with it cannot be opened with the old reader anymore. Is there some place where the reader saves its temporary files in order to delete them?

This is indeed strange. What happens when you try doing that?
But btw, I think your chances of getting an answer may increase if you ask your question in the general firmware thread. What we are discussing here is unrelated to the new pdf reader.

[thorgal]

Originally Posted by janek

This is indeed strange. What happens when you try doing that?
But btw, I think your chances of getting an answer may increase if you ask your question in the general firmware thread. What we are discussing here is unrelated to the new pdf reader.

Well it is another bug which happens only since i installed the 1.7 20120726 FW. But you are right i will ask there too.

What happens when i try to open any PDF (using the old "standard" PDF reader) which have been previously opened with the new beta reader, the loading icon freezes and the document never opens. Once opened with the beta reader it only can be opened again using the beta reader. Only PDFs never opened with the new reader can be opened with the old one. I supposed there is some sort of temporary files the beta reader creates which "interfere" with the old reader.

[Knorke]

Originally Posted by thorgal

I am suffering another annoying bug related with the beta PDF reader: Any PDF document opened with it cannot be opened with the old reader anymore. Is there some place where the reader saves its temporary files in order to delete them?

Hi thorgal,

I've switched between beta and standard pdf reader because of the merging problem and I could open the pdf file in any case. In principle the pdf files are not changed even if you scribble or annotate something. These informatation are storered in the hidden folder .onyx. Perhaps you should try to delete its content.

[thorgal]

Thanks. I took a look at it and there is only a file called sketch or something related to the last file i opened. Nothing related to the files i had problems with. In any case i just developed my own homemade remedy. I simply renamed the "contaminated" files and now the old reader can open them without a problem.

[Knorke]

Originally Posted by thorgal

... is only a file called sketch or something related to the last file i opened. ...

Yes, the file *.pdf.sketch contains information about scribbles and annotations you've made in the original pdf. Just try to rename the sketch file which is related to your "contaminated" file (same file name + .sketch).

Edit: I've observed problems with graphics in pdf files. In some cases it takes up to 15 seconds to open the page containing pages with these graphics+text. Taking notes works very very slowly in this case (this bug I want to discuss when the merging bug is solved). Do you have graphics in your document?

[thorgal]

There were not sketch files related to "contaminated" files in /.onyx only to the last file i opened (with the old reader btw) which was not "contaminated". Maybe the beta reader stores some info related to the files which has previously opened in another place. In any case the solution i found (changing the name of the document file itself) proves the document itself has not been in any way modified by the beta reader.

Edit: I've observed problems with graphics in pdf files. In some cases it takes up to 15 seconds to open the page containing pages with these graphics+text. Taking notes works very very slowly in this case (this bug I want to discuss when the merging bug is solved). Do you have graphics in your document?

No graphics (necessarily). It happens the same with plain text small PDFs and large complex documents.

[janek]

Originally Posted by thorgal

There were not sketch files related to "contaminated" files in /.onyx only to the last file i opened (with the old reader btw) which was not "contaminated". Maybe the beta reader stores some info related to the files which has previously opened in another place. In any case the solution i found (changing the name of the document file itself) proves the document itself has not been in any way modified by the beta reader.


No graphics (necessarily). It happens the same with plain text small PDFs and large complex documents.

Take a look into /root directory. But be careful - it is not clear if modifying, let alone deleting these files is 100% safe. You will need a sqlite editor to modify them, such as sqliteman.
But if I were you, I'd consider resetting the device (using the hole in the back cover)