Contenu | Rechercher | Menus

Annonce

Si vous rencontrez des soucis à rester connecté sur le forum (ou si vous avez perdu votre mot de passe) déconnectez-vous et reconnectez-vous depuis cette page, en cochant la case "Me connecter automatiquement lors de mes prochaines visites".
Test de l'ISO d'Ubuntu francophone : nous avons besoin de testeurs pour la version francophone d'Ubuntu 14.04. Liens et informations ici.
nombre réponses : 25

#0 Re : -1 »  MultiSystem, Créez votre LiveUSB MultiBoot simplement! [2] » Le 16/10/2013, à 15:45

roger64
Réponses : 702

Bonjour

Je viens de m'apercevoir que la dernière version de Parted Magic, tout en restant avec la licence GPL, est devenue payante au téléchargement (environ 5 dollars). Cela va t-il poser un problème de soutien pour Multisystem? Si c'est le cas que convient-il de faire?
- cesser de l'utiliser parce qu'elle n'est plus supportée (et donc - pour moi au moins - inutilisable)
- te faire passer une copie pour que tu en assures le soutien même si c'est sans l'autorisation de l'auteur?
- autre solution, par exemple écrire à l'auteur pour obtenir les paramètres techniques (???) de l'iso

#1 Re : -1 »  Echecs: Scid et ses fans » Le 22/11/2013, à 06:20

roger64
Réponses : 598

L'open source à la fête!!

1385093624.png

Brillante qualification de Stockfish pour la super finale du nTCEC season2. Il y affrontera son plus proche rival Komodo. Les précédents champions ont disparu: Rybka ne s'est même pas qualifié dans les six premiers et Houdini s'est fait proprement étriller par Stockfish au cours de la dernière étape (voir copie d'écran).

Cela faisait longtemps qu'un moteur open source n'avait pas été à pareille fête dans un championnat si relevé. Ses supporters espèrent qu'il ne se ressentira pas trop des efforts consentis et qu'il sera en mesure de gagner la finale. tongue

#2 Re : -1 »  Live Voyager » Le 06/10/2013, à 07:31

roger64
Réponses : 2493

hors sujet

Raah, trop tard pour moi.

J'ai acheté vendredi dernier une Deskjet 2510 (HP) pour remplacer une Deskjet 2100 qui avait effectivement des problèmes de cartouche (durs à détecter, il a fallu que je passe sur W7 pour avoir l'info). Certes la cartouche n'était pas de chez HP mais elle était pratiquement neuve (quelques pages à peine). Je n'ai pas osé acheter Canon car j'ignorais qu'il supportait aussi bien Linux. La prochaine fois... smile

/hors sujet

Bonne continuation à Voyager. À tout hasard pour me faire pardonner, quelques infos qui pourraient potentiellement vous intéresser.

J'utilise aussi Xfce en distribution d'appoint (SolydX et des dépôts dérivés de Debian) installable avec le menu Whisker et le Xfce-theme-manager. L'une des fonctions qui me manquaient depuis Gnome était les nautilus-scripts. Je trouve que les Thunar actions ne sont pas très conviviales - j'ai sûrement tort - et j'ai bien une douzaine de petits scripts que j'utilise régulièrement. Installer Nautilus (que Gnome persiste à châtrer) entraîne aussi l'installation d'une horde de dépendances (70 megs environ) inutiles. J'ai trouvé une solution de rechange: j'ai installé Nemo (10 megs tout compris) qui a gardé toutes les fonctionalités d'origine de Nautilus et je puis désormais sans problèmes continuer à utiliser mes scripts avec un clic droit.

#3 Re : -1 »  Live Voyager » Le 06/10/2013, à 08:03

roger64
Réponses : 2493
PPdM a écrit :

Les cartouches adaptables sont de la fumisterie, cela reviens bien plus cher a la page que celle d'origine car elles moins de pages et il faut souvent renforcé la densité pour avoir les mêmes couleur et sur les Canon et les Epson ça bouche les têtes d’impressions.

D'accord avec toi. On l'apprend avec l'expérience... En fait, j'ai utilisé avec succès pendant quelques années une imprimante laser avec des toners que je réutilisais. Puis j'ai été contraint de changer d'imprimante (plus compatible) et effectivement je viens d'apprendre que ce n'est pas pareil avec les cartouches...

#4 -1 »  [résolu] Changer unités de mesure sur feuille de style CSS » Le 04/06/2014, à 22:23

roger64
Réponses : 15

Bonjour,

Dans le domaine des livres électroniques (format EPUB), certains convertisseurs produisent des feuilles de style CSS (stylesheet.css) avec des valeurs de marge, de padding, d'indentation, etc. fixées en centimètres, millimètres, voire en  pixels, c'est-à-dire avec des unités à valeur fixe. L'unité conseillée pour les EPUB est cependant l'em qui varie selon la valeur de la police choisie.

Il existe des convertisseurs centimètre vers em.
Le rapport pour une police à 100% est 1cm=2.37106301584em
Inversement: 1em=0.421175176em

Les feuilles de style sont des séries de paragraphes de ce genre:

p.Citation {
  margin-left: 0.499cm;
  margin-right: 0.499cm;
  margin-top: 0;
  margin-bottom: 0;
  border: none;
  padding: 0;
  text-indent: 0.499cm;
  text-align: justify;
  font-family: "Charis SIL ModifiedLarger";
}

L'expression contenant l'unité à convertir commence toujours avec un deux-points et finit avec un point-virgule. J'aimerais disposer d'un script qui me permette de convertir en em les valeurs en centimètres contenues dans une feuille de style et je n'ai pas la moindre idée de la façon dont on peut s'y prendre.

#5 Re : -1 »  [résolu] Changer unités de mesure sur feuille de style CSS » Le 05/06/2014, à 08:03

roger64
Réponses : 15

Bonjour

pingouinux ou la bonne fée! J'ai essayé sur une grosse feuille de style et cela fonctionne très bien! Merci beaucoup de ton intervention.
Il y a quelques points mineurs que je souhaiterais compléter:

1. - j'aimerais obtenir une sortie  converted.txt (ou mieux converted.css) à côté du fichier converti.

2. - la valeur line-height est fréquemment donnée dans les feuilles de style de la façon suivante, sans unité de valeur:

line-height: 1.2;

Dans ce dernier cas, cependant, il ne s'agit pas de centimètres mais d'une unité relative qu'il ne faut pas convertir. Il conviendrait donc que le script ne fonctionne que lorsque l'unité de valeur (en l'occurrence ici cm) est explicitement mentionnée. Dans le cas ci-dessus, il ne devrait rien toucher.

3. - La précision avec deux décimales est suffisante. Comment obtenir un résultat à deux décimales qui minimiserait l'erreur obtenue? Ou, pour le dire différemment, vaut-il mieux ôter des décimales avant ou après conversion?

#6 Re : -1 »  [résolu] Changer unités de mesure sur feuille de style CSS » Le 05/06/2014, à 09:49

roger64
Réponses : 15

Bonjour

Je reconnais bien sûr mes torts.  smile  Ton script fonctionne parfaitement bien et ne modifie désormais que les unités en cm.

Merci beaucoup de ton aide, brillante, comme d'habitude!!

#7 Re : -1 »  [résolu] Changer unités de mesure sur feuille de style CSS » Le 06/06/2014, à 15:56

roger64
Réponses : 15

Bonjour

@pingouinux

J'ai montré ton script sur MobileRead et j'ai demandé s'il était possible d'écrire un script qui puisse modifier directement les fichiers css qui se trouvent dans un EPUB:

Voici le résultat qui fonctionne qu'il y a ait une ou plusieurs feuilles de style dans l'EPUB. La seule différence pour moi, est que pour le lancer, je dois d'abord spécifier l'interpréteur: python et la commande de lancement devient donc.

Ex;

python cm2em.py vieux.epub nouveau.epub

Encore merci pour ton aide.

#!/usr/bin/env python

import sys, re
import datetime, zipfile

class zip_info(zipfile.ZipInfo):
    def __init__(self, *args, **kwargs):
        if 'compress_type' in kwargs:
            compress_type = kwargs.pop('compress_type')
        super(zip_info, self).__init__(*args, **kwargs)
        self.compress_type = compress_type
        
def convertcm2em(epub, stylesheet):
    conv=2.37106301584
    unit=re.compile('([^\d.]+:\s*)([\d.]+)(cm)?(;\s*)')
    new_sheet = ''
    with epub.open(stylesheet) as f:
        for lig in f :
            k=unit.search(lig)
            if k :
                unite=k.group(3)
                if unite=='cm' :
                    val="%.2f"%(conv*float(k.group(2)))
                    unite='em'
                    lig=k.group(1)+val+unite+k.group(4)
            new_sheet+=lig
    print '  Checking: ', stylesheet
    return new_sheet

def main(argv=sys.argv):
    if len(argv) != 3:
        print '\nUsage:'
        print '  cm2em.py <infile.epub> <outfile.epub>'
        return 1
    if argv[2]==argv[1]:
        print '\n  Outfile cannot be the same as infile!'
        return 1
    with zipfile.ZipFile (argv[1], 'r') as zin, zipfile.ZipFile (argv[2], 'w') as zout:
        for item in zin.infolist():
            if (item.filename[-1:] != '/'):
                buf = zin.read(item.filename)
                if (item.filename[-4:] == '.css'):
                    converted_sheet = convertcm2em(zin, item.filename)
                    if converted_sheet == buf:
                        zout.writestr(item, buf)
                    else:
                        now = datetime.datetime.now()
                        zip_date = (now.year, now.month, now.day, now.hour, now.minute, now.second)
                        nzinfo = zip_info(item.filename, date_time=zip_date, compress_type=zipfile.ZIP_DEFLATED)
                        zout.writestr(nzinfo, converted_sheet)
                else:
                    zout.writestr(item, buf)
    return 0

if __name__ == '__main__':
    sys.exit(main())

Je l'ai testé sur plusieurs livres et il y a un cas - rare - où la conversion ne se fait pas: c'est pour un style de bibliographie où il y a un indent négatif.

text-indent: -0.5cm;

#9 Re : -1 »  [résolu] Changer unités de mesure sur feuille de style CSS » Le 08/06/2014, à 22:12

roger64
Réponses : 15

Bonjour

En poursuivant mes essais, je suis tombé sur une feuille de style rétive. La conversion ne se fait pas. J'ai allégé la feuille de style car il n'y a que quelques valeurs en centimètre, plutôt au début de la feuille. Les styles sont bien écrits de la même façon mais la forme est condensée comme ceci:

a:link {color:#000080;text-decoration:underline}
a:visited {}
body {font-size:1em;margin-bottom:0cm;margin-left:0.5cm;margin-right:0.5cm;margin-top:0cm}
body.nomargin {margin-bottom:0cm;margin-left:0cm;margin-right:0cm;margin-top:0cm}
div.amanuensis-center-div {margin-bottom:0cm;margin-left:0cm;margin-right:0cm;margin-top:0cm;text-align:center}
img.amanuensis-fullscreen-image {height:100%;margin-bottom:0cm;margin-left:0cm;margin-right:0cm;margin-top:0cm;max-width:100%}
p.P100 {color:#000000;font-size:1.25em;font-style:italic;font-weight:normal;margin-bottom:0em;margin-left:0em;margin-right:0em;margin-top:0.0694488188976378em;orphans:2;text-align:center;text-indent:0em;widows:2}
p.P101 {color:#000000;font-size:1em;font-style:normal;font-weight:normal;margin-bottom:0em;margin-left:0em;margin-right:0em;margin-top:0.0868110236220473em;orphans:2;text-align:center;text-indent:0em;widows:2}
p.P102 {color:#000000;font-size:1em;font-style:normal;font-weight:normal;margin-bottom:0em;margin-left:0em;margin-right:0em;margin-top:0.0868110236220473em;orphans:2;page-break-after:auto;page-break-before:auto;text-align:justify;text-indent:0em;widows:2}

On m'a demandé quelle version de Python tu avais utilisé pour écrire le script?

EDIT: en fait la version originale du script intervient sur cette feuille de style mais cause des dégâts en supprimant par exemple les mentions body, div, img....

#10 Re : -1 »  [résolu] Changer unités de mesure sur feuille de style CSS » Le 09/06/2014, à 06:09

roger64
Réponses : 15

Bonjour

Merci de répondre encore présent. Je te prie d'accepter mes excuses. Le premier script  fonctionne bien pour toutes les feuilles de styles qui ont été "embellies", c'est-à-dire préalablement nettoyées par l'éditeur de Calibre et qui se présentant sous la forme que je t'avais donné dans le premier message.

C'est en élargissant les tests que je suis tombé sur ce type d'écriture condensé qui est effectivement différent même s'il suit les règles du CSS. Dans ce deuxième cas, pour que le script fonctionne, il fallait que j'"embellisse" la feuille de style au préalable pour retomber dans le cas initial.

EDIT: J'ai  testé ton nouveau script sur des feuilles condensées et embellies et il fonctionne bien pour les deux. Je viens de l'adresser sur MobileRead au deuxième auteur. Pour ton information,  Kovid Goyal, l'auteur de Calibre vient aussi de participer spontanément à cette discussion.

Si tu veux suivre et/ou participer à la discussion en anglais, c'est ici: http://www.mobileread.com/forums/showth … p?t=240536
L'intervention de Kovid Goyal est au post #20.

#11 Re : -1 »  [résolu] Changer unités de mesure sur feuille de style CSS » Le 09/06/2014, à 16:21

roger64
Réponses : 15

Bonjour Tamarou

On change, on ne peut pas toujours répéter la même chose... smile
Depuis deux ans, j'utilise LMDE 64 bits et ma liseuse Kobo Glo est aussi sur Linux.

@pingouinux

Je te cite une remarque de notre co-auteur:

"Note that pingouin's regex in the new conversion routine will miss the last property/value pair in the class (when it doesn't end with a ";").

body {font-size:1em;margin-bottom:0cm;margin-left:0.5cm;margin-right:0.5cm;margin-top:0cm}

becomes:

body {font-size:1em;margin-bottom:0.00em;margin-left:1.19em;margin-right:1.19em;margin-top:0cm}

Note the margin-top property at the end. It obviously won't matter when the value is zero, but it will when it's not."

Il fait allusion au fait que dans un paragraphe consacré à un style, il n'est pas obligatoire de mettre un point-virgule juste avant l'accolade fermante et beaucoup s'en abstiennent. Le raisonnement derrière cela est que les points-virgule ne servent qu'à séparer les arguments et qu'il n'y a plus rien de ce genre à séparer avant l'accolade fermante.

Je ne sais combien de "découvertes" de ce genre je vais encore faire et je prie Dieu pour que je n'aie pas encore épuisé tes trésors de patience... La bonne nouvelle est que l'intégration du script va être grandement facilitée par l'intervention de Kovid Goyal.

#12 Re : -1 »  [résolu] Changer unités de mesure sur feuille de style CSS » Le 09/06/2014, à 21:30

roger64
Réponses : 15

@pingouinux

Merci de ton aide. Je commence à avoir chaud...

Voici la nouvelle version baptisée cm2em_v3. Les deux parties ont été revues.

#!/usr/bin/env python

from __future__ import print_function
from __future__ import unicode_literals

import sys, re
import datetime, zipfile

class zip_info(zipfile.ZipInfo):
    def __init__(self, *args, **kwargs):
        if 'compress_type' in kwargs:
            compress_type = kwargs.pop('compress_type')
        super(zip_info, self).__init__(*args, **kwargs)
        self.compress_type = compress_type

def convertcm2em(epub, stylesheet):
    conv=2.37106301584
    unit=re.compile('(:\s*)(-?[\d.]+)(cm)?(;|})')
    new_sheet = ''
    fic=epub.read(stylesheet).decode('utf-8')

    while True :
        k=unit.search(fic)
        if(k) :
            new_sheet+=fic[:k.start(1)]
            new_sheet+=(k.group(1))
            val=k.group(2)
            unite=k.group(3)
            if unite=='cm' :
                val="%.2f"%(conv*float(k.group(2)))
                unite='em'
            else :
                unite=''
            new_sheet+=val+unite
            new_sheet+=k.group(4)
            fic=fic[k.end(4):]
        else :
            new_sheet+=fic
            break
    print ('  Checking: ', stylesheet)
    return new_sheet

def main(argv=sys.argv):
    if len(argv) != 3:
        print ('\nUsage:')
        print ('  cm2em.py <infile.epub> <outfile.epub>')
        return 1
    if argv[2]==argv[1]:
        print ('\n  Outfile cannot be the same as infile!')
        return 1
    with zipfile.ZipFile (argv[1], 'r') as zin, zipfile.ZipFile (argv[2], 'w') as zout:
        for item in zin.infolist():
            if (item.filename[-1:] != '/'):
                buf = zin.read(item.filename)
                if (item.filename[-4:] == '.css'):
                    converted_sheet = convertcm2em(zin, item.filename)
                    if converted_sheet == buf.decode('utf-8'):
                        zout.writestr(item, buf)
                    else:
                        now = datetime.datetime.now()
                        zip_date = (now.year, now.month, now.day, now.hour, now.minute, now.second)
                        nzinfo = zip_info(item.filename, date_time=zip_date, compress_type=zipfile.ZIP_DEFLATED)
                        zout.writestr(nzinfo, converted_sheet)
                else:
                    zout.writestr(item, buf)
    return 0

if __name__ == '__main__':
    sys.exit(main())

#13 Re : -1 »  [résolu] Changer unités de mesure sur feuille de style CSS » Le 10/06/2014, à 09:06

roger64
Réponses : 15

Et le dernier avatar du script lancé avec Calibre smile

avec la commande suivante qui modifie l'epub original (copie fortement conseillée...) et implique que l'epub soit dans le répertoire de travail

calibre-debug cm2em_calibre.py file.epub

Le nouveau code

from __future__ import print_function
from __future__ import unicode_literals

import sys, regex
from calibre.ebooks.oeb.polish.container import get_container, OEB_STYLES

def convertcm2em(raw):
    conv=2.37106301584
    unit=regex.compile('(:\s*)(-?[\d.]+)(cm)?(;|})')
    new_sheet = ''

    while True :
        k=unit.search(raw)
        if(k) :
            new_sheet+=raw[:k.start(1)]
            new_sheet+=k.group(1)
            val=k.group(2)
            unite=k.group(3)
            if unite=='cm' :
                val="%.2f"%(conv*float(k.group(2)))
                unite='em'
            else :
                unite=''
            new_sheet+=val+unite
            new_sheet+=k.group(4)
            raw=raw[k.end(4):]
        else :
            new_sheet+=raw
            break
    return new_sheet

c = get_container(sys.argv[-1], tweak_mode=True)

for name, mt in c.mime_map.iteritems():
    if mt in OEB_STYLES:
        raw = c.open(name).read()
        new = convertcm2em(raw)
        if new != raw:
            print ('  Modifying:', name)
            c.open(name, 'wb').write(convertcm2em(raw))
        else:
            print ('  No changes to:', name)
            
c.commit()

#14 Re : -1 »  [résolu] Changer unités de mesure sur feuille de style CSS » Le 14/06/2014, à 19:03

roger64
Réponses : 15

Bonjour

@pingouinux

Cela n'a pas raté, il y a eu une autre "trouvaille" comme tu le craignais: en effet, j'avais tout simplement oublié de te signaler la notation abrégée (shorhand)... roll  Mais rassure-toi, le problème a été réglé d'une autre façon.

Comme je te l'avais dit, Kovid Goyal est intervenu une deuxième fois. Du coup, la solution adoptée utilise une fonction de Calibre (avec Python) et non plus directement Python. Comme tu le sais, je ne maîtrises bien peu de choses dans ce domaine mais si cela t'intéresse, tu trouveras sur ce fil MobileRead en français, le texte du script nouvelle formule. Il est possible de faire du traitement par lot.

http://www.mobileread.com/forums/showth … ost2851172

Encore très sincèrement merci pour ta contribution efficace qui a permis de démarrer cela.

#15 Re : -1 »  Script pour récupérer les métadata d'un livre. » Le 29/04/2014, à 14:50

roger64
Réponses : 5

Bonjour

J'ai changé d'identifiant au passage (j'ai rajeuni d'un numéro) mais ta remarque est - évidemment - parfaitement judicieuse. big_smile
Je vais voir comment marquer résolu.

Merci.

#16 Re : -1 »  Script pour récupérer les métadata d'un livre. » Le 29/04/2014, à 15:02

roger64
Réponses : 5

... mais malheureusement, le script ne fonctionne pas encore et me crache un .txt vide.

#!/bin/bash

# Paquets nécessaires: zenity, calibre

name=$(zenity --entry --title "Titre du livre recherché" --text "Titre du livre recherché" --entry-text=Nom?)
echo "name=$name"

fetch-ebook-metadata -t  "${name}"  > "${name}".txt

echo "Terminé"
zenity --info --text "Terminé"

En fait , il y a un mieux en ce sens qu'avant d'envoyer "terminé", il semble qu'il respecte la période de latence. J'obtiens "terminé" non plus immédiatement mais au bout de trente secondes, ce qui est logique. Mais le fichier .txt reste vide.

#17 Re : -1 »  Script pour récupérer les métadata d'un livre. » Le 29/04/2014, à 17:51

roger64
Réponses : 5

Décidément, il faut qu'on me prenne par la main. Oui, ça fonctionne. big_smile

Le numéro isbn est donné sans les traits d'union habituels, je ne sais pas pourquoi. De la même façon, beaucoup de titres (tous les titres) perdent leurs accents. Je suppose sans en être sûr que c'est les contraintes de la base de données. En tout cas, c'est bien pratique pour avoir la date exacte de publication, le résumé, etc.

Pourquoi Amazon? Je suppose que c'est pour la même raison que l'on exporte aux formats EPUB et/ou AZW3: le poids des parts de marché.

Merci encore pour ton aide sympa.

#18 Re : -1 »  Vos avis sur LibreOffice 4.0 (vos tests, suggestions et critiques) ! » Le 01/12/2013, à 12:17

roger64
Réponses : 250

Bonjour

J'ai vu qu'avec la 4.1 on pouvait désormais lire des polices Open-Type (et leurs ligatures) et incorporer une police dans un document.

La première nouveauté constitue un plus indéniable qui était souhaité depuis longtemps. Je suis plus réservé quant à l'utilité pratique de la seconde.

J'ai fait un essai avec un texte de deux lignes: cela fonctionne mais le document a désormais une taille de 3.2Mo... En fait, il me semble que LibreOffice s'est arrêté à mi-chemin. Il faudrait que l'on puisse incorporer, non la police complète avec ses quatre ou six fontes, mais simplement un sous-ensemble de cette police, contenant uniquement les glyphes contenus dans le document. Cette remarque reste valable même si l'on publie un gros texte (livre).

Il existe des sites en ligne qui le font mais ce n'est pas très pratique à utiliser. Calibre permet de le faire en ligne de commande sur un EPUB. Je ne sais pas s'il cette technique pourrait s'appliquer à un fichier odt. En attendant cela, je crains que l'utilisation de cette nouveauté ne reste limitée qu'à des cas où il est absolument indispensable d'incorporer la police (langues rares et autres cas particuliers de ce genre) alors qu'elle pourrait devenir d'usage courant et nous permettre enfin de sortir de l'usage des polices Microsoft dont nous sommes devenus, bon gré mal gré, dépendants.

#19 Re : -1 »  Vos avis sur LibreOffice 4.0 (vos tests, suggestions et critiques) ! » Le 01/12/2013, à 14:47

roger64
Réponses : 250

Bonjour

Il n'y a rien d'anormal. Il s'agissait de la police Linux Libertine version 5.3 otf qui fait effectivement un peu plus de trois mégas installée sur mon ordinateur (avec les fontes normal, italiques, gras et gras-italiques). Je l'utilise régulièrement en l'incorporant dans mes EPUB mais en tant que sous-ensemble. Elle ne fait plus alors que 400k (avec les fontes normal et italique) ce qui est déjà conséquent mais pas énorme. Il devrait d'ailleurs être possible d'obtenir un sous-ensemble d'une taille encore plus réduite mais il faudrait d'autres outils de création que calibre, du genre InDesign ou autres que je ne connais pas.

Vous pouvez faite l'essai en installant la police en question. La version otf (OpenType) est excellente.

http://sourceforge.net/projects/linuxli … ine/5.3.0/

Il est souhaitable effectivement de ne réaliser un sous-ensemble que pour un texte considéré comme fini, et destiné à la publication. Mais, pour sur un texte courant de type "occidental", on peut sans problème effectuer les corrections orthographiques, etc... Du moins avec la pratique que j'en ai (rassurez-vous, les sous-ensembles créés par calibre sont taillés large!).

#20 Re : -1 »  Vos avis sur LibreOffice 4.0 (vos tests, suggestions et critiques) ! » Le 03/12/2013, à 06:23

roger64
Réponses : 250
Smon a écrit :

C'est la fin des ennuis ! smile

Bonjour

Hélas, non...  smile C'est peut-être le début de la fin des ennuis (ou si vous préférez un pas dans la bonne direction) mais vous ne pourrez utiliser en pratique de "vraie" police (c'est à dire complète) pour les raisons de taille que j'ai données plus haut tant que vous n'aurez pas la possibilité d'incorporer un sous-ensemble.

Ce qui est offert actuellement ne me paraît utilisable que pour des cas particuliers (langues rares, police exotique etc.) mais expliquez-moi comment vous pensez généraliser par exemple l'usage de Linux Libertine dans votre entreprise s'il faut ajouter à chaque document, quelle que soit sa taille, 2 ou 3 Mo supplémentaires? Cela me paraît irréaliste.

Avant que cette "révolution" des polices ne puisse avoir lieu, il sera nécessaire de mettre à disposition des utilisateurs un outil compatible avec LibreOffice capable de générer et d'incorporer un  sous-ensemble de taille raisonnable. Ce n'est pas de la science-fiction: des outils open-source comme calibre disposent de telles fonctions (pour le format EPUB) même s'ils sont à mon avis encore très perfectibles.

#21 Re : -1 »  Vos avis sur LibreOffice 4.0 (vos tests, suggestions et critiques) ! » Le 03/12/2013, à 15:45

roger64
Réponses : 250
JBF a écrit :

bonjour,

Si tu veux généraliser l'usage d'une police précise dans ton entreprise, le plus simple est quand même de la faire déployer sur tous les postes de travail par ton service informatique.

Je n'ai pris qu'un exemple. Pour assurer le respect de la charte graphique de l'entreprise dans ce domaine, il faudra quand même incorporer cette police spécifique dans tous les documents au format odt qui sortiront de l'entreprise même si la police en question est déjà déployée sur tous les postes de travail. Si le format export n'est pas le format odt, le problème est bien sûr différent.

JBF a écrit :

Il me semble que l'intérêt de pouvoir embarquer une police dans un document concerne effectivement seulement les polices exotiques et/ou propriétaires dont on peut supposer que le destinataire du document aura quelques difficultés à se les procurer. Dans les autres cas, il n'est pas compliqué d'installer les polices manquantes. Dans la mesure où on a pris conscience qu'elles manquent ...

On est bien d'accord à ce sujet. C'est pourquoi je dis que ce n'est qu'un premier pas et pas très pratique à ce jour en raison de la taille excessive des polices embarquées. Par ailleurs, à l'exception des polices open-source (ou sous licence libre), on ne peut pas incorporer n'importe quelle police dans un document sans accord de licence, mais là aussi c'est un autre problème...

#22 Re : -1 »  Vos avis sur LibreOffice 4.0 (vos tests, suggestions et critiques) ! » Le 03/12/2013, à 17:23

roger64
Réponses : 250

Bonjour

Il y a beaucoup de polices de ce genre sous licence libre (par exemple les google web fonts  http://www.google.com/fonts). Ces web-fonts sont soit des sous-ensembles de polices complètes soit n'offrent qu'une partie (une fraction dans certains cas) des glyphes d'une police complète. Tout utilisateur peut se créer "sa" web-font en fonction de ses besoins propres - ou plutôt de ceux de son document. J'avais utilisé pour de nombreux livres un sous-ensemble de Linux Libertine avec des web-fonts de 60k chacune (regular, italic, smallcaps). Leur registre d'emploi était  limité à quelques langues occidentales. On peut  par exemple créer des web-fonts sur mesure avec cet outil:
http://www.fontsquirrel.com/tools/webfont-generator

Il faudrait ensuite que l'utilisateur de LibreOffice installe ces web-fonts comme s'il s'agissait de police système pour qu'il puisse les incorporer dans ses documents. Mais j'avoue avoir un peu de peine à renoncer à toutes les possiblités qu'offre une police complète. et cela est d'autant plus vrai dans un cadre professionnel. Si l'on doit publier un document comportant par exemple des mots grecs, il faudrait créer une nouvelle version de ses web-fonts (regular, italic...), les installer pour ensuite les incorporer... Pas très pratique.

Calibre se contente de tailler à grands coups de hache. Le résultat - moyen en termes de réduction de taille - n'est pas ciselé mais on obtient en deux ou trois secondes une police réduite parfaitement utilisable pour le document demandé. On en revient finalement à la possibilité - manquante aujour'dhui avec LibreOffice mais ô combien souhaitée -  de créer pour ses documents un sous-ensemble adapté à partir d'une police complète.

#23 Re : -1 »  Vos avis sur LibreOffice 4.0 (vos tests, suggestions et critiques) ! » Le 08/12/2013, à 02:35

roger64
Réponses : 250

Bonjour

Il suffit de faire une recherche avec les mots "font subset tool" pour trouver de nombreux autres projets de ce genre. Voici à titre d'information un lien vers la bibliothèque opensource d'un projet intialement développé par Google qui permet de créer des sous-ensembles. Il ne s'agit pas de l'outil en tant que tel mais de la bibliothèque permettant de développer - eventuellement - un tel outil.
http://code.google.com/p/sfntly/

Bien entendu, les PDF disposent en interne d'outils de ce genre (quoique moins agressifs me semble t-il, plutôt à la façon de Calibre) depuis très longtemps mais le code reste la propriété d'Adobe.

#24 Re : -1 »  Cinnamon!! » Le 24/09/2013, à 09:08

roger64
Réponses : 438

Bonjour

Quelques informations complémentaires sur l'UP 7

L'UP7 (LMDE) a été validée il y a a quelques jours  et est maintenant en place dans tous les dépôts Latest. C'est une mise à jour massive (la précédente remontait quand même à décembre 2012) comprenant de 1200 à 1500 paquets suivant votre installation. En dépit de cela, elle n'est pas accompagnée d'une ISO. Clément Lefebvre en a donné la raison sur son blog à la fin août: Cinnamon est actuellement incompatible avec Gnome Shell. C'est soit l'un, soit l'autre. Il faudra attendre la sortie de Cinnamon 2.0 pour retrouver une version compatible avec Gnome Shell et pour obtenir la nouvelle ISO LMDE. Ceci pourrait arriver en fin d'année, voire en janvier 2014.

Les utilisateurs de Mate, qui ont reçu à la fin août une grosse mise à jour (de 1.4 vers 1.6), devraient également recevoir une nouvelle mise à jour (de 1.6 vers 1.8) à l'occasion de la sortie de cette future ISO.

Cinnamon 2.0 devrait arriver d'abord dans Petra (Linux Mint 16) quelques semaines après Ubuntu 13/10 sur lequel il est en grande partie basé. Le volume restreint de l'équipe de Mint ne lui permet pas de développer simultanément plusieurs versions de sa distribution. D'ici la fin de l'année on verra donc se reproduire le cycle précédent avec les sorties successives de  Petra Cinnamon, Petra Xfce, Petra KDE suivies enfin de LMDE Cinnamon (UP 8).