• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Plugins
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Version 3.1
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Robert - 2008-11-13
Last edited by Yoshihisa Uchida - 2010-03-17

FS#9546 - UTF-8 BOM "visible" in viewer

I have created some .txt files in UTF-8 format with Byte Order Marks (BOMs), using Windows XP SP3 Notepad and OpenOffice 3.0 Writer. In the viewer options I have set UTF-8 encoding. All the characters are correctly displayed, but at the beginning of each file there is strange rectangle that represents BOM. I have done a research and found out that BOM handling in Rockbox core was corrected by this patch –, but described issue is present in viewer plugin.

I know one can save without BOM, using Notepad2, but BOM allows Windows to recognize the UTF-8 file automatically, which is useful - for example it allows Wordpad and Lister to correctly open UTF-8 .txt files. So, as somebody is using .txt files both with Rockbox and Windows, the proper BOM handling by Rockbox is useful.

Closed by  Yoshihisa Uchida
2010-03-17 12:20
Reason for closing:  Accepted
Additional comments about closing:  

patch commits.

Yoshihisa Uchida commented on 2009-01-21 09:20

I create the patch file.

Please confirm it.

Jonathan Gordon commented on 2009-01-21 09:39

I’m not sure that is the best way to go about fixing this….
I cant think of many places in the core where the text file position is as important for seeking as it is in viewer so I tihnk its better to fix viewer to be smarter than to waste code in the core for something which will only be used in a plugin

Dominik Riebeling commented on 2009-01-21 16:51

I put together a patch for this as well a bit ago (but forgot to post it here). The main problem I have with this is the fact that the viewer tries to align reads with the disk sectors. Both the above patch and my version (which is slightly more compact as it doesn’t introduce a specific filesize function – you can easily do this by using open_utf8() and then substracting the current byte position) break this functionality.

Yoshihisa Uchida commented on 2009-01-22 07:35

Gordon, Riebeling comment thanks.

My patch file found some problems.
When the problem is solved, the patch file will upload.

When I correct the patch file, *_utf8() functions will not use. (Then, viewer.c changes only)

Riebeling, because it might take time to correct the patch file, I think that you may upload your patch file where you are made without waiting for my correction.

Yoshihisa Uchida commented on 2009-01-22 10:25

Because the correction of problems was completed, a new patch file upload.

Yoshihisa Uchida commented on 2009-02-13 03:32

When the patch of  FS#9855 ,  FS#9892 ,  FS#9893 , or  FS#9898  is applied, the patch of this task cannot be applied.

Even if you forcibly apply the patch file, it doesn’t operate correctly.
Oppositely, even if you apply these patches after you apply the patch of this task, it doesn’t operate correctly.

If you want to apply the patch of  FS#9855  (or  FS#9892 ,  FS#9893 ,  FS#9898 ), you must use the patch file of  FS#9899  (this task is closed).

Yoshihisa Uchida commented on 2009-02-21 03:50

Because the patch file of  FS#9899  is old, I send a new patch.
Please apply the patch in order of  FS#9855 ,  FS#9892 ,  FS#9893 ,  FS#9898 ,  FS#9902 ,  FS#9853  and this patch.

If you do not apply these patch files, this patch need not be applied.

Yoshihisa Uchida commented on 2009-03-05 13:36

sync the patch file.

Yoshihisa Uchida commented on 2009-06-17 09:18

sync r21316

Yoshihisa Uchida commented on 2010-02-20 05:57

sync 24782


Available keyboard shortcuts


Task Details

Task Editing