- 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
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.
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.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
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, orFS#9898is 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(orFS#9892,FS#9893,FS#9898), you must use the patch file ofFS#9899(this task is closed).Because the patch file of
FS#9899is old, I send a new patch.Please apply the patch in order of
FS#9855,FS#9892,FS#9893,FS#9898,FS#9902,FS#9853and this patch.If you do not apply these patch files, this patch need not be applied.
sync the patch file.
sync r21316
sync 24782