Bonjour,
J'ai ce problème de temps à autre, je ne sais pas si c'est lié à Grammalecte ou à LibreOffice (je penche plutôt pour LO)

J'utilise la police Libertinus Math, et son ensemble de glyphes mathématiques, pour une meilleure robustesse du document.
Exemple :
www.dropbox.com…

Dans ce document, les lettres A, V, et v, sont obtenus dans le jeu « symboles mathématiques alphanumériques »

Il semble que l'utilisation de ce jeu de glyphes pose problème. Ainsi, l'absence d’espace après la parenthèse n'est pas souligné au bon endroit.
Le problème se pose aussi avec la police Cambria Math, et beaucoup de sujets de concours qui utilisent massivement cette police ont le même soucis

Qu'en pensez-vous ?

Pierre
PS :
de gain différentiel 𝐴 (𝑉ᵣ = 𝐴·𝑣H)et associé

La correction se fait bien avec Grammalecte et FireFox

Bonjour,

Je viens de faire le test avec Python et ça fonctionne correctement : l’erreur est bien positionnée.
Cela signifie que pour une raison interne à LibreOffice le positionnement est décalé, sans doute parce que la représentation interne des chaînes de caractères n’est pas en UTF-8, me semble-t-il. Du coup, le problème survient probablement pour tous les caractères trop éloignés dans la table Unicode.

Le problème, c’est le codage des caractères en interne et probablement “leur taille”.

Je m'en doutais.
Le problème pour décrire ce bug chez LO, c'est :
1 - mon anglais déficient, en particulier pour ce genre de problème
2 - c'est Grammalecte je crois, qui fait apparaître le problème, il faudrait que la mise en évidence du bug soit indépendante de Grammalecte
3 - l'intérêt discutable à passer du temps pour remonter un bug qui a peu de chance d'être corrigé

Je vais déjà voir si je le fais apparaître sans Grammalecte

Merci
Pierre

Finalement, dans mon élan, j'ai rédigé un rapport du bug :

bugs.documentfoundation.org…

Un peu comme un bouteille à la mer, on verra bien

Pierre

Mieux vaut rapporter les bugs, même si la chance de les voir rapidement corrigés est faible.

Oui, vous avez raison, mais parmi les près de 11 000 bugs reportés et confirmés...

Merci pour le complément sur le rapport de bug

Le document de test fait systématiquement planter AOO lorsque Grammalecte est installé (0.4.10.7) dès son ouverture

AOO utilise Python 2.7. Pas sûr qu’il sache gérer ces caractères correctement. Ou bien il y a un bug dans cette vieille version de Grammalecte, mais ça n’a a priori aucun rapport direct.

Ou bien AOo plante lorsqu'il fait appel à une fonction qui pose problème.

Avec un document configuré pour l'anglais, et le dictionnaire anglais, il y a plantage dès que l'on fait un clic droit sur le soulignement qui n'est pas positionné sur l'erreur. Mais on peut ouvrir le document.

Le positionnement du soulignement et le plantage sur un clic droit n’ont a priori aucun rapport direct, même si ça peut être la même cause (des caractères spéciaux). Mieux vaut éviter de tout mélanger.

oui,sauf si c'est le calcul de la position du soulignement qui fait planter dans un cas (Aoo) et qui donne un résultat erroné dans l'autre (LO). Encore que dans les deux cas, le positionnement est mauvais.
Il y a eu dans LibreOffice un tas de correction de bug via des outils d'analyse (CoveretyScan et Google). Peut-être est-ce le résultat de ce travail qui fait la différence ici.

Je me disais que le document en anglais faisait appel à une fonction de AOO au moment du clic-droit, et que dans le document en français, c'était Grammalecte qui faisait appel à cette fonction dès l'ouverture du document.

Mais vous avez raison, les problèmes peuvent être indépendant et il faut éviter les apriori

Dans le correcteur grammatical, ce n’est pas Grammalecte qui fait appel à LO, c’est LO qui fait appel à Grammalecte. Grammalecte est un service, et comme service il ne fait que servir, il ne commande rien, aussi surprenant que ça puisse paraître.

À mon avis, il y a de grandes chances que ce problème du mépositionnement des erreurs est dû à la représentation interne du texte de LO/AOO, qui si j’ai bonne mémoire utilise UTF-16, tandis que Python fonctionne avec UTF-8.
Il y a des différences dans la manière de compter la longueur des chaînes de caractères Unicode : hsivonen.fi… (c’est même un beau bordel).

Bonjour,

Effectivement avec le texte "de gain différentiel 𝐴 (𝑉ᵣ = 𝐴·𝑣H)et associé" en utf8 le 𝐴 en utf8 a une longueur de 1 caractère en utf16 il fait 2 c'est a peu près pareil pour les autres symbole mathématique de se texte donc le décalage si LO est en utf16 deviens vite important... au finale en utf8 le texte fait 44 et en utf16 48 ;)

Ce qui est presque sure c'est que si c'est effectivement un problème d'encodage les développeurs de LO ne vont rien faire vu que ce n'est pas un bug de leur part.

Que le problème ne vienne pas de LO, cela se discute, car en théorie quand on indique une position d’erreur, on parle bien de caractères, pas de bytes ou quoi que ce soit dans la représentation interne de LO. En théorie, une API, c’est fait pour simplifier la tâche.

Mais, peu importe, je suis en train de corriger ce problème en faisant des conversions manuelles.
Je fournirai une version bêta à tester bientôt.

Problème corrigé. Préversion à tester intensément :
[[ fichier supprimé ]]

Le problème semble corrigé, les premiers essais sont concluants.

A voir dans la durée

Bravo pour la réactivité
Pierre

Dans ce fichier :
www.dropbox.com…

L'insertion du point proposé par Grammalecte provoque l'insertion d'un curieux caractère.

Avec la version 2.1.3b de Grammalecte

Mise à jour : grammalecte.net…