| Summary: | SPREADSHEET. Not found international characters composed with accents compounds | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | gmolleda |
| Component: | Calc | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED NOTABUG | ||
| Severity: | normal | CC: | gmolleda |
| Priority: | medium | ||
| Version: | 4.1.3.2 release | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
| Attachments: |
BUG in file. Error en el fichero. Eraro en dosiero
character not found in LibreOffice. |
||
Created attachment 89526 [details]
character not found in LibreOffice.
Ohhh. The bug is not in VLOOKUP, it is in copy-paste text from Firefox Browser to LibreOffice SpreadSheet.
The difference:
BAÑEZ <== not detected with tool search
CAÑA <== detected with tool search
If you copy-paste this text (open the file .txt attached), you will see the difference to search in LibreOffice.
Gedit (gnome editor) found both words and no problem.
As far as I understand ODF standard, all arguments of the formula must use the same normalization form. Otherwise the behavior is undefined, as we can see in that case. The problem is: If the character is a simple code of 8 or 16-bit works fine, but if the character is composed of one single and added a symbol above, then treat them as two different characters though they occupy the same position: Ñ can be Ñ or a N followed by ~, in the latter case if looking N you can find it but if you looking Ñ you will not find it. Same with other international characters: A+', S+˘, ... In my case, the Ñ is B__A__N__+_~____E__Z__=_BAÑEZ is BAN+~EZ and LibreOffice finds N and not Ñ 42 41 4E + CC83 45 5A C__A___Ñ___A__=_CAÑA is ok. LibreOffice finds Ñ 43 41 C391 41 |
Created attachment 89524 [details] BUG in file. Error en el fichero. Eraro en dosiero I have imported a class list downloaded from the virtual learning platform, with various data. But before the list was also taken from the same platform elsewhere, from which I selected, copied and pasted the list directly (use Linux Debian Wheezy), but in this I was missing some data. In seeking to relate the two listings using the VLOOKUP function to ensure there are no errors, I find that the names with Spanish characters like Ñ not feeling well. Attached file with the problem. If I write a word Ñ directly, yes the find, could be a problem of encoding types and although I watch a Ñ may be internally encoded in UTF-8 and other UTF-16 or ISO-8859-1 or something. En español: Yo he importado una lista de clase descargada de la plataforma de enseñanza virtual, con varios datos. Pero antes tenía la lista también sacada de la misma plataforma en otro lugar, de donde seleccioné, copié y pegué el listado directamente (uso Debian Linux Wheezy), pero en este me faltaba algún dato. Al querer relacionar ambos listados usando la función buscarv para asegurar que no hay errores, me encuentro que los nombres con caracteres como la Ñ española no los encuentra bien. Adjunto fichero con el problema. Si escribo directamente una palabra con Ñ, sí la encontraría, podría ser un problema de codificiación y aunque yo vea una Ñ puede que internamente una esté codificada en UTF-8 y otra en UTF-16 o en ISO-8859-1 o algo así. Esperanto is neutral: Mi importis klaso listo malŝarĝi de la virtuala lernado platformo, kun diversaj datumoj. Sed antaŭ ol la listo ankaŭ estis prenitaj el la saman platformon aliloke, el kiu mi selektis, kopiitaj kaj batitaj la listo rekte (uzu Linukso Debian senspira), sed pro tio mi mankis iujn datumojn. En serĉas rilatigi la du listojn uzante la VLOOKUP funkcion certigi ne ekzistas eraroj, mi trovas ke la nomoj kun hispana gravuloj kiel Ñ ne sentante bone. Kuna dosieron kun la problemo. Se mi skribas vorton Ñ rekte, jes la trovos, povus esti problemo de kodigo tipoj kaj kvankam mi rigardi Ñ povas esti interne kodita en UTF-8 kaj aliaj UTF-16 aŭ ISO-8859-1 aŭ io.