Rockbox

  • Status Closed
  • Percent Complete
    100%
  • 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 inrobert - 2008-11-13
Last edited by 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 – http://www.rockbox.org/tracker/task/6203?pagenum=3, 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  Uchida
2010-03-17 12:20
Reason for closing:  Accepted
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

patch commits.

I create the patch file.

Please confirm it.

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

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.

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.

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

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).

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.

sync the patch file.

sync r21316

sync 24782

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing