xryl669 a écrit 94 commentaires

Ouais, enfin bon. Si tu as déjà regardé un document de dépot de brevet, tu as vu qu'il contient des schémas, des liens, des références, des tables, etc… Je te mets au défi de me montrer 2 logiciels sachant gérer de l'ODT sans casser la présentation. Pire encore avec le DOCX dans un logiciel dont le modèle de document est calqué sur l'ODT.

Dans la pratique, il existe des soft opensource qui font du DOCX en natif (je pense à OnlyOffice), je vois pas pourquoi il faudrait que toutes les personnes qui travaillent avec l'INPI doivent passer par des logiciels différents, avec moins de fonctionnalité pour faire de "ODT", alors que leur base de travail quotidienne est en DOCX.

Je ne comprends pas les ayatollah de l'ODT qui estiment que leur format est supérieur. Je peux comprendre qu'un format propriétaire et fermé soit inférieur, soit parce qu'il faut passer à la caisse, ou parce qu'on ne sait jamais si le document s'ouvrira encore dans la version 2030 du logiciel, mais ce n'est pas le cas du DOCX.

Il existe des soft open source qui l'ouvre parfaitement (puisque le format n'est pas propriétaire, ni fermé) et qui sont gratuits. À nous de nous adapter au monde extérieur et pas l'inverse!

1. Oui
2. Oui
3. docx, xlsx, pptx c'est le format (de fait) utilisé partout où les gens travaillent avec les outils et pas sur les outils.

Complètement d'accord avec le dernier point. Onlyoffice est pour l'instant plus limité dans son interface que LibreOffice ou MS Office (malgré le fait qu'il supporte quasiment toutes les fonctions dans les fichiers OOXML). C'est la suite que l'on attendait en open source, car ça marche avec les autres sans les obliger à changer leurs habitudes.
Le format ODT, c'est beau comme un poème, c'est à dire en théorie, mais sans pragmatisme. C'est un format issu d'une suite office (StarOffice/OpenOffice) qui était peu utilisée, incompatible de fait avec le format "de facto". Impossible de faire tenir OOXML dans ODT, donc c'est à perte pour l'utilisateur qui veut utiliser le format.
Je tire mon chapeau au dev LibreOffice, mais depuis que j'ai compris qu'il n'y a aucune chance qu'un document DOCX soit ouvert correctement avec, c'est fini pour moi. Le seul cas où je démarre encore LO, c'est pour les tableurs car il supporte les fonctions statistiques (ex. régressions linéaires) nativement (alors que OnlyOffice n'a pas d'interface pour créer la régression linéaire, mais si elle est présente dans le fichier source, il sait la tenir à jour).
LO est aussi mieux optimiser pour les très gros tableaux (genre 50k cellules) alors que le code d'OnlyOffice rejette le document.

Oui, enfin bon. Quand tu vis dans la vraie vie, le format ODF (ODT/ODS/ODP) ça ne marche pas, le DOCX et XLSX et PPTX oui, et seul OnlyOffice le supporte correctement.

D'ailleurs, en réalité, le format DOCX est le plus problématique. Pour les tableurs et présentations, ça marchouille suffisamment pour que ce soit acceptable. Mais pas pour les documents textes.

Après avoir cherché pourquoi LibreOffice, malgré les années et les nombreux contributeurs était toujours incapable d'ouvrir un DOCX non basique correctement (et encore moins de l'enregistrer sans le casser), j'ai trouvé que le problème d'OO ou LO, c'est le modèle de document (qui a servi de base au format ODF d'ailleurs).

Ce modèle ne supporte pas toutes les fonctions que l'on retrouve dans le format DOCX. Du coup, lors de l'ouverture d'un DOCX il essaye de mapper le modèle DOCX sur son modèle inférieur, perdant, au passage, beaucoup d'information. Par exemple, DOCX supporte les ancres relatives d'un objet par rapport à un autre. ODS ne supporte que les ancres relatives par rapport à la page, ou au paragraphe. Dans un dessin dans Word, impossible donc de l'ouvrir dans LO sans que ça ne le casse (sans parler du reflow lorsque l'on ajoute/modifie le texte). Je peux t'en citer plein d'autre comme ça.

Donc, l'argument comme quoi la spec ODF est plus simple, oui et heureusement car elle ne fait pas tout ce que fait la spec XMLX.

Honnêtement, entre l'interface OnlyOffice et LibreOffice, y a pas photo, je préfère largement la première malgré le manque de fonctions dans le frontend (paradoxalement, leur backend est super puissant)

Je veux pas jeter la pierre, mais Microsoft a passé largement plus de temps et d'amélioration pour que son format de document soit vraiment adapté à un maximum de cas concrets (l'avantage d'être le seul à le maîtriser vs devoir se coller à une spécification) et je vois pas comment LO pourra le rattraper sauf à modifier le modèle de document, ce qui est quasiment impossible lorsque celui-ci est normalisé.

Donc, pour moi, c'est une beau mouvement de la part de Microsoft, en publiant son format XMLX et poussant pour que l'ODF soit normalisé (en l'état, donc inférieur), il a bloqué toute compétition car l'ensemble des efforts de la communauté open source est maintenant perdue à vouloir se "conformer" à une norme inférieure.

En plus "joli", il y a SimpleEmail disponible sur F-Droid. Il a une interface material (avec les swipe pour effacer les messages, aperçu des messages etc…). C'est à la base un fork de FairEmail, mais avec un contributeur plus à l'écoute des besoins des utilisateurs.

Comment vous faîtes pour Edge qui ne supporte pas les SSE ? C'est du polling ?

Justement, je suis assez étonné de cette réponse "même par une extension".
Vu que ladite extension serait téléchargée hors de l'app store: (exemple, le store des extensions de chrome qui ne passent pas par l'App Store)
1) Comment Apple peut-il le savoir ?
2) Même s'il le sait, actuellement, le texte qui interdit d'utiliser un autre moteur que Webkit est celui ci (de https://developer.apple.com/app-store/review/guidelines/ :)

4.4 Extensions

Apps hosting or containing extensions must comply with the App Extension Programming Guide or the Safari Extensions Development Guide and should include some functionality, such as help screens and settings interfaces where possible. You should clearly and accurately disclose what extensions are made available in the app’s marketing text, and the extensions may not include marketing, advertising, or in-app purchases.
[...]
4.7 HTML5 Games, Bots, etc.

Apps may contain or run code that is not embedded in the binary (e.g. HTML5-based games, bots, etc.), as long as code distribution isn’t the main purpose of the app, the code is not offered in a store or store-like interface, and provided that the software (1) is free or purchased using in-app purchase; (2) only uses capabilities available in a standard WebKit view (e.g. it must open and run natively in Safari without modifications or additional software); your app must use WebKit and JavaScript Core to run third party software and should not attempt to extend or expose native platform APIs to third party software; 

Je comprends, du 4.4 qu'une extension est autorisée si il n'y a pas de marketing, pub, ou achat in-app.
Du 4.7, puisque l'extension n'est pas l'application principale (dans ce cas), qu'elle n'est pas fournie via un store, qu'elle serait gratuite, ça devrait passer. Après je ne suis pas un avocat.

Autant, c'est génial pour android, autant sur iOS, on se sent un peu seul.
D'un côté Apple verrouille à l'utilisation de son webkit limité/ant, de l'autre on voudrait de l'alternative (libre en plus).
Est-ce que vous envisagez de faire une version pour iOS de Focus avec Gecko ? (par exemple, comme une extension téléchargeable ultérieurement, afin de ne pas être backboulé par la pomme lors de l'upload de l'application  ?)

Ce serait une petite révolution sur iOS, qui le mériterait bien.

La monnaie libre a opté pour un système permettant une symétrie spatiale et temporelle en appliquant simplement une vitesse de croissance du DU. l’augmentation quantitative du DU permettant "d'oublier" progressivement les DU anciens. Un système simple et parfaitement efficace pour limiter les effets d'accaparement. La conséquence étant (dans un cas théorique sans échanges) une convergence naturelle des comptes vers la moyenne de la masse monétaire par individu. Les comptes élevés comme les compte très faibles convergent selon une asymptote vers cette moyenne d'autant plus fortement qu'ils en sont éloignés.
Un peu comme un élastique demande de plus en plus d'efforts pour s'éloigner de son point d'attache (la moyenne), l'enrichissement demandera de plus en plus d'efforts pour s'en éloigner.

Autant mathématiquement, cela pourrait revenir au même, autant psychologiquement, ce n'est pas le cas.

Lundi:

• Bonjour, combien pour la baguette de pain ?
• 10 G

Mardi:

• Bonjour, combien pour la baguette de pain ?
• 15 G

Mercredi:

• Bonjour, combien pour la baguette de pain ?
• 21 G

Pour moi, en tout cas, je préfère quand les valeurs sont stables, je peux plus facilement les comparer, les appréhender, m'en souvenir. Dans le scénario ci-dessus, je te mets au défi de savoir, de tête, combien va te coûter ta baguette dans 93 jours. Auras-tu assez d'argent de côté si tu épargnes maintenant ? Est-ce que mettre de l'argent en banque sera rentable, vu la "croissance" de la monnaie ?

Bref, une valeur qui varie est insupportable.
Paradoxalement, une valeur de référence qui se dévalue lors de l'échange l'est beaucoup moins. La baguette vaudra toujours 10 T, seulement si tu veux la payer avec l'argent de ton salaire de l'année dernière que tu as mis de côté, il faudra débourser 11 T. Après tout, c'est exactement ce qui se passe actuellement avec la monnaie-dette, sauf que l'opération est validé à la transaction, au lieu de la lourdeur des impôts (déclarations, TVA, etc…). Le 1T de différence repart dans le circuit économique comme un "impôt", une TVR (taxe sur la valeur retirée).

À propos des échanges extérieurs, c'est tout à fait possible de faire des échanges avec d'autres monnaies d'ailleurs, mais le taux de change dépendra de la valeur non dévaluée de référence, c'est à dire une valeur qui ne fait qu'augmenter avec le temps. C'est un peu le principe que vous appliquez à l'intérieur du DU, mais uniquement pour l'extérieur.

La notion de liberté est très utopique. Aucun système ne peut fonctionner sans "la mort et les taxes", car l'humain livré à lui-même est cupide et peu prévoyant en général. Il est difficile de sous réserve de liberté, laisser des personnes sans protection santé, sans assurance civile, etc… Il n'y a qu'à voir au USA ce qui se passe.
Le problème des taxes et autres, c'est dans l'iniquité de leur création/évaluation et l'utilisation qui en sont faites. Si le système de monnaie dévalue en fonction d'un vote démocratique qui a spécifié les taxes (montants, objets, résultats) et donc le taux de dévaluation, il n'y a plus d'iniquité. Évidemment, il ne faut pas concentrer le pouvoir de vote dans les mains d'un nombre limités d'acteurs comme c'est le cas dans notre démocratie, mais justement, le pouvoir des ordinateurs/algorithmes c'est de garantir la justice et l'équitabilité du vote.

La toile de confiance est trop "statique", voire binaire. C'est déjà pénible à créer au début, j'imagine combien se serait difficile à virer sa confiance dans un individu (pour que tout le monde le fasse).
Mon idée est plus granulaire, une personne qui améliore le système par son comportement est sujette à un meilleur retour du système qu'une personne qui, sciemment, dégrade le système. C'est l'effet nudge.

Pour moi, une monnaie libre ne peut être basée sur les mêmes principes que les autres monnaies.
Philosophiquement, le libre c'est quoi ?
Pour moi, c'est, à la source, la combinaison du temps passé par le développeur/maker et de son expérience (acquise ou pas ailleurs) et la volonté de partager son Oeuvre avec d'autres.
Le "consommateur" profite de l'effort fourni par la source souvent gratuitement (l'un des critères fondamentaux) ou ouvertement (il peut modifier l'Oeuvre).

Un comportement que je trouve abject est celui qui profite de l'Oeuvre en la monétisant sans rétribuer la source, celui qui plagie la source sans apport intéressant, celui qui empêche la source de continuer son activité, etc…

Pour moi, une monnaie libre devrait permettre à des sources de vivre de leur activité tout en rendant la tâche plus difficile pour les "abjects".

Dit différemment, la monnaie devrait comprendre des mécanismes évitant les mauvais comportements et récompensant les bons.

Une des idées présentées pour cela, c'est d'associer une "réputation" à chaque individu utilisant une telle monnaie, réputation qui serait consommée pour faire des actions avec la monnaie et qui serait régénérée lorsque d'autres utilisent ou apprécie l'effort/l'Oeuvre de la source (c'est un peu l'idée de Steem, sauf que …)
En gros, je prends un risque en recommandant telle source ou effort, mais quand d'autres commencent à utiliser les Oeuvres en question, je suis remercié du risque pris par une amélioration de ma réputation.
Inversement, si je spécule comme un fou sans améliorer (je con-somme en détruisant), ma réputation va tomber en flèche, et j'aurais de plus en plus de mal à faire des opérations.

Ensuite, il faut que la monnaie se dévalue à chaque transaction (ce qui évite les "collectionneurs / cupides / riches") et également en fonction du temps (celui qui garde un trésor des années ne vaut plus rien car la transaction de "vente" dévaluera son bien en fonction de la durée d'acquisition). Le montant de la dévaluation repart dans le système et est, soit distribué entre les membres de manière équitable (c'est une sorte d'impôt à la "source"), soit utilisé pour les Oeuvres communes (écoles/formation, soin, bref tout ce qui sert au bien commun).
La dévaluation pourrait être modulée en fonction de la réputation (plus une personne a un comportement utile à la communauté, plus sa réputation est élevé et moins la dévaluation s'applique à elle).

Enfin, et c'est là le plus difficile, il faut éviter les échanges avec d'autres monnaies classiques (sinon les protections contre la spéculation / thésaurisation ne sert plus à rien). Je trouve aussi que c'est plus juste, car après tout, l'argent… c'est du temps. On a tous le même capital de temps, c'est la seule chose universelle qui a la même valeur partout sur Terre.

Enfin, il faudrait que tout comportement "abject" soit pénalisé par la perte de réputation voire le bannissement.

En gros, la TRM et le dividende universel donne de la valeur au temps (c'est bien en soit), mais pas en l'utilisation "utile" de ce temps. Le piège, c'est l'oisiveté, s'il ne faut fournir aucun effort pour cette rémunération.
Un tel système à grande échelle amènera, sans aucun doute, des "super conglomérats" qui vont centraliser l'acquisition des ressources des autres. Résultat, le dividende universel ne servira jamais à rien, car quelque soit le montant, le prix des services de base augmentera en conséquence, le DU ne sera jamais suffisant.

C'est l'exemple des APL prévues initialement pour permettre l'accès à des logements de meilleurs qualités et qui, au final après quelques mois, sont principalement absorbés par les propriétaires qui ont augmentés les loyers du montant des APL.

Bref, il est absolument nécessaire que le mécanisme de la monnaie empêche ce comportement. Il ne faut pas une autre monnaie cupide.

J'adore ce que fait Snips, c'est vraiment au top, clair, bien développé.

Pourriez-vous également fournir un modèle pseudo-complet de toutes les phrases-types classiques ?
Car le code sans modèle ne sert pas à grand chose et le modèle avec 3 phrases pour la météo, même s'il marche, ne sert pas à grand chose.

À ce que j'ai compris, vous avez comparé votre réseau pour le NLU aux autres "grands" gaffeurs du domaine, je déduis donc que vous devez avoir des corpus super gros pour ça. Pouvez-vous les partager? Sinon, connaissez-vous un lien vers de tel corpus libre, pour le français?

Dans la même veine, Mozilla common voice est en train de finaliser sa version internationale pour le projet Common Voice, se qui devrait permettre d'avoir, très bientôt j'espère, un corpus d'audio + transcription libre en Français.

Car pour faire un assistant libre, il faut, certes, du code libre, mais des modèles libres. Aujourd'hui la partie STT (speech to text) est majoritairement basée sur Kaldi. Seulement, impossible de trouver des modèles libres en Français pour Kaldi. Kaldi n'est pas non plus au top en terme de WER (en comparaison de la concurrence). C'est l'oeuf et la poule, tant qu'il n'y a pas de modèle libre, Kaldi n'est utilisé que pour du prototypage/recherche, et donc ne concerne que les pros du domaines. Du coup, il n'y a pas l'effet de masse qui inciterait des milliers de développeurs à améliorer Kaldi pour atteindre les performance d'un Google API.

Avec un WER de 9% (c'est déjà très très bien), ça veut dire que l'engine NLU doit pouvoir marcher correctement avec 1 mot sur 11 pourri. Comment tester ça dans votre code sans modèle ?

Oui, mais c'est lourd à écrire, à lire et donc à maintenir. C'est ça le problème.

Certes, mais en même temps, exposer dans ta sérialisation le nom du membre (côté programme) est vraisemblablement une mauvaise idée.

Je comprends ta remarque, mais ce dont tu parles c'est d'avoir la possibilité de filtrer le "nom" des membres. L'un n'empêche pas l'autre. Dans 95% des cas, tu veux un 1:1 entre la sérialisation et ta classe, donc le code devrait pouvoir faire cela directement, et pour les 5% restant, tu peux intercepter et/ou filtrer. La proposition d'introspection (qui sera dans C++20 probablement) le permettra justement.

Ça c’est une très mauvaise idée. Si j’appelle un membre qui n’existe pas, je m’attends à une erreur de compilation, pas une erreur à l’exécution. Changer ça dans le contexte de C++, c’est, quelque part, casser le langage.

Justement, c'est tout l'intérêt du constexpr ici. Par défaut, un tel opérateur entraînerait une erreur "membre machin non trouvé" donc le comportement sera 100% identique à l'état actuel.
Par contre, si l'opérateur est présent, alors soit il est constexpr et peut être vérifié à la compilation (donc un comportement entre le mode dynamique/runtime et le mode figé/statique).
Ceci serait très utile justement pour éviter les "outils" de génération qui écrivent du code illisible (type mock ou autre gsoap).
Exemple d'application, les membres namespace:attribute du XML, l'opérateur pourrait vérifier que le nom du membre "inconnu" que l'on veut vérifier commence par le nom du namespace attendu, par exemple.
Ou que les membres ajoutés commencent par "signal_" ou "slot_", si tu vois ce que je veux dire.

Ensuite, si l'opérateur n'est pas constexpr, le compilateur pourrait te jeter pour chaque appel dont le nom du membre est fixe à la compilation (avec un warning du genre "Ce serait mieux si tu ajoutais un membre machin à ta classe").

Enfin, tu l'utilises comme une classe dynamique au runtime (donc tu ne connais pas le nom des membres à priori), et tu utilises l'introspection pour les retrouver. C'est faisable actuellement avec une table de hash, mais c'est pas natif, donc pas optimal.

En bref, tu as le choix, c'est justement ça pour moi l'intérêt principal du C++

Je suis tout à fait d'accord. Concernant la POO, le standard C++17 n'apporte rien de transcendant. Franchement, avoir des fonctionnalités d'introspection en 2017, je ne pense pas que ce soit si superflu (à l'heure où quasiment toute donnée est transmise en JSON). Il n'y a pas une seule bibliothèque C++ aujourd'hui qui sache faire de la sérialisation sans avoir à déclarer chaque champs 2 fois (une fois pour la compilation "statique" et une fois pour le runtime). C'est assez pénible.

De même, avoir des objets dynamiques, sans se taper des tuple à rallonge qui sont vraiment mauvais niveau praticité et performance et maintenabilité, à part pour la performance, c'est franchement manquant. Alors qu'il suffirait d'ajouter un opérateur pour "membre non trouvé" à gérer au runtime, du genre

  struct MyClass {
      int foo;
      string bar;
      runtime_members __otherMembers; // A bit like a map<any>

      template <class T> any operator .(const string & name, const T & arg ) { return __otherMembers[name] = arg; }
  };

  MyClass a;
  a.foo = 3;
  a.bar = "hello";
  a.baz = "world"; // call operator .
  a.qux = 4.5;     // ditto

Lorsque le compilateur rencontrerait un membre non présent, il appellerait l'opérateur "." (qui peut static_asserter si le nom n'est pas acceptable, ou remplir les champs au runtime.

C'est marrant, j'ai exactement l'avis opposé. Je trouve beaucoup plus intuitif de faire obj.methode() pour une action que func(obj).
Mon commentaire, n'était pas pour ajouter des méthodes à std::string, mais pour dire que l'interface initiale est pourrie, car trop basée, comme pour les premières classes de la STL, sur des idées 1980 (code ASCII 8bits, tout le monde parle anglais, etc…), et pas assez sur l'utilisation de l'objet lui-même. Dans la réalité des codes utilisant du std::string que j'ai lu (et j'en lis beaucoup), 99.9% du temps, les indices sont inutiles, plein de bugs, etc…

L'exemple le plus flagrant, c'est lorsque je dois faire l'i18n d'une appli C++. Le développeur ne sait pas (ou a "oublié") qu'il travaillait avec de l'UTF-8, et estime, à tort que l'index d'un caractère est égal à sa position en mémoire. Avec une interface sans index à gérer, il n'y a aucun soucis. Avec std::string, c'est l'horreur. Avec une classe utilisant le pattern "from_first", "upto_last", etc, ça roule tout seul.

Traduire le code des iostreams c'est aussi une autre hérésie qui n'aurait jamais dû survivre à plus d'un standard. Le grand classique, que j'ai vu à de nombreuses reprises, c'est "cout << "There is " << animal_count << " pet" << animal_count ? 's' : '\0' << " in the store."<< endl;
En général, là, le code est à réécrire (grand moment de solitude). Franchement, séparer la présentation des données, même le C le faisait en 89 avec printf et gettext, le C++ n'y est toujours pas (il y a boost::format mais bon… boost quoi…).

De plus, l'interface des string aurait due être séparée en "méthodes" non modifiantes, "méthodes modifiantes", quitte à faire une classe "readonly_string" qui permette les recherches, les modifications de taille (ou du pointeur de début de chaîne) mais pas du contenu de la chaîne (bref: tout ce qui est requis pour parser du texte), et une classe "writeable_string" pour le reste, en ayant un héritage multiple des deux interfaces dans ce qui s'appelle la classe string. Du coup, la problématique du COW disparaît automatiquement suivant que l'on veuille en payer le prix ou non (pour le parsing, par exemple, pas de COW pour du RO).

C'est sûr, alors qu'une bonne expression régulière aurait fait des miracles en un seul appel.
Ceci dit, le pattern Fluent est vraiment agréable à utiliser (pour ceux qui font du JQuery, lodash, etc… par exemple, impossible de penser autrement maintenant).

Le vrai problème du code ci dessus vient de la signature de la fonction replace qui modifie la chaîne au lieu de retourner une nouvelle string. Si cela avait été le cas, alors l'ordre d'appel, on s'en balance. Avec un replace immutable, alors il faut, logiquement faire la recherche de la sous chaîne par la fin pour garantir que les modifications soient appliquées au bon endroit.

Mais au final, on retombe encore sur les signatures bancales de la classe string, qui ne propose qu'un nombre limité de méthodes (au nom d'une simplification de l'implémentation STL, mais qui, en pratique, force chaque projet à réimplémenter les fonctions de bases avec tous les bugs que ça impliquent). Un string replace(const string & this, const string & by_that) serait alors bien plus simple et dans la majorité des cas (le reste, c'est faisable par un erase + insert). De même pour tout ce qui est basé sur des index en fait, dans la majorité des cas, c'est inutile et vraiment pénible dès lors que l'on fait du UTF-8.

Un code comme ceci est bien plus compréhensible:

String s = "The blue cat doesn't like the yellow dog";
return s.replace("yellow", "blue").replace("blue", "yellow").replace("dog", "cat").replace("cat", "dog");
// Autre exemple, plus concret
String get_authority(const String & url) {
// Exemple: url = "http://whatever.org/path/to/index.html";
return url.from_first("://").to_first("/");
}

Le deuxième exemple, montre que, même si en interne la classe utilise des index pour trouver les sous chaînes, ils ne sont pas visibles dans la signature des méthodes, et donc c'est carrément plus intuitif. Côté performance, avec du COW, c'est mieux que du code à base de find & replace, vu qu'il ne faut plus "sortir" les index de la stack dans les fonctions supérieures, une seule fonction appelée, moins de registres utilisés et donc, au final, tourne beaucoup plus vite.

Visiblement, vous n'avez pas fait votre travail de googlemineur!
Blagues à part, pour avoir une synthèse qui ne fasse plus so 1980, la meilleure solution actuelle est Voxygen ou NeoSpeech en anglais.
Pour l'utiliser sous Linux, il y a 2 solutions.
La première solution, sur un linux basé sur Arm ou x86, c'est d'acheter le package Android à 3€ et d'utiliser la librairie qui va bien pour porter les API android sur un Linux normal (type libhybris).
L'autre solution, à 39€, c'est d'utiliser les voix Best-Of-Vox de Voxygen, via Wine (c'est le plus simple) mais c'est limité à x86.
Voir ce blog pour le "HOW-TO". Cette dernière solution fonctionne avec Speech-dispatcher.

Et puis, il y a aussi MaryTTS qui est une référence (non listée dans la liste des moteurs de synthèse) et qui s'améliore de mois en mois (qui a 3 voix en français).
Et Cereproc qui est la solution la plus ouverte sous linux (ça coûte 79€ si je me rappelle bien), mais il faut programmer pour l'utiliser (ce qui est un avantage pour moi, mais pas pour ceux qui veulent du "speech-dispatcher" compatible)

Pour conclure, aujourd'hui, ce qui limite la qualité de la voix de synthèse, c'est le manque de matériel audio correctement taggué pour pouvoir faire du "unit selection" (meilleure technologie actuelle). Ça demande un temps très important, et c'est pourquoi nous n'avons pas de modèle en Français gratuit et libre. Franchement, vu la qualité d'un Cereproc ou Voxygen (cocorico), pour le prix, j'hésite pas une seconde, je préfère passer mon temps à coder que d'enregistrer 50h d'audio à tagguer manuellement pour sortir un modèle qui sonne bien.

"Bref, une majorité de fautes typiques de tout développeur en C++."

Bravo!
Sauf que…
En fait, il n'y a aucun rapport. Les problèmes énoncés sont n'ont rien à voir avec le langage de programmation.
En quoi l'interprète JS utilisé pour "recompiler" le code JS asm.js en code natif a un rapport avec le langage utilisé ?
Il pourrait être écrit en Java / brainfuck, c'est le "code compilé généré" qui est fautif, donc l'algorithme, et pas le langage.
Le lien CSS et SVG non plus (qui est en C et pas C++), l'XML compressé qui est probablement dans zlib (en C), ou les metadata du MP4 (Vala? asm ?) bref…
Du C++ bashing de base, sans fondement, dommage, c'est raté, la prochaine fois, peut-être ?

Pour information, tout projet sérieux (qui se dit l'être) utilise des vérificateurs statiques (AddressSanetizer / Clangtidy) et dynamiques (Valgrind), Firefox n'y faisant pas exception. Et ce n'est pas parce que il est écrit en C++ que c'est nécessaire (d'ailleurs, les mêmes vérificateurs sont utilisés pour des programme qui utilise du Ruby, du Fortran, du Python, du Vala, etc..), parce que on ne vit plus dans sa bulle, on linke avec des libraries écrites dans d'autres langages et que les erreurs mémoires arrivent dues à une mauvaise compréhension des API de ses librairies.

Bref, ce commentaire réduit l'intérêt de l'article, et montre le sérieux des préjugés de l'auteur.

Moi, je ne le comprends pas comme ça. Je comprends qu'il ne faut pas supprimer le logo Onlyoffice pour y mettre le tien. Rien ne t'interdit de changer le code pour faire l'interface que tu veux (y compris, déplacer ou supprimer le champ contenant le logo), du moment que tu ne t'appropries pas la marque et que tu laisses, quelque part dans ton interface (même dans une boite "à propos") le logo original d'Onlyoffice.

C'est de AGPL3, une sorte de GPL qui t'oblige à garder la source, un peu comme Flowplayer, Pydio etc… Après, on s'habitue vite à des licenses sans aucune contrepartie, mais vue l'ampleur du travail réalisé, je trouve juste de leur accorder un minimum de respect/hommage.

Tu dis: "Le correcteur ne sait pas où chercher une conjugaison adéquate. Pour parfaire le système de suggestion, il faudrait établir des passerelles entre tous les mots grammaticalement distincts sur leurs liens phonétiques éventuels."

Il me semble qu'il existe dans les entrées du dictionnaire un représentation phonétique de chaque mot (sinon, ces dictionnaires existent en opensource, par exemple chez eSpeak pour la synthèse vocale, LLIUM pour la reconnaissance vocale, etc…).
Du coup, en ajoutant une n-ième passe au préprocesseur (lors de la détection d'une erreur), qui aurait pour entrée l'index des mots en "phonétique" qui, par définition est un mapping 1:n, pourrait lors d'un mot incongru (Il s'en "fou"), chercher si un des résultats pour l'entrée phonétique "fu" pourrait convenir. Dans ce cas aussi simple, il trouverait immédiatement le verbe conjugué, et n'aurait plus qu'à choisir la bonne conjugaison parmi "fous, fout".

Après, avec un TernarySearchTree indexé sur les clés phonétiques, on pourrait même envisager une recherche approximative (type Levenshtein, distance de Hamming) pour trouver des mots dont la phonétique est "proche" de l'item erroné - Cela ne donnerait pas de faux positif puisque ceci démarrerait uniquement sur détection d'une erreur, tel qu'actuellement. On est alors clairement dans l'aide à l'utilisateur, au lieu de détecter une erreur et de ne pas savoir quoi suggérer, on pourrait envisager un menu "Ils son faux." => "son" est erroné, vouliez vous dire "sont", "sonnent" etc…

Concernant "Il est aller à la mairie", je pense qu'une dernière passe de pre-processing utilisant la technique des n-gram, (c'est à dire la découpe en entités de 3/4 lettres), puis comparaison avec un modèle statistique du langage (tel que fournis par Google en opensource), repèrerait l'incongruité statistique de la suite "est aller". C'est ce que fait Google pour ses suggestions de correction de recherche. Il faut définir des seuils (donc risque de faux positifs) quitte à laisser le seuil à 0 par défaut et laisser les utilisateurs aventureux à monter le seuil.