Author: Federico Basmadyian

Deuxième épisode de la mini série consacrée au tri dans FileMaker.

Introduction

Configurer les différents tris possibles dans un mode liste, en cliquant sur les libellés en tête des colonnes, peut s’avérer rapidement laborieux à faire, d’autant plus si votre solution comporte de nombreux modèles en mode liste avec le même système de tri.

En effet, FileMaker ne propose malheureusement aucun mécanisme natif permettant de choisir les rubriques de tri de manière dynamique, ce qui force à concevoir des scripts de tri remplis de très nombreuses conditions afin de lancer le bon tri suivant l’en-tête de colonne cliquée, et donc la valeur passée en paramètre au script de tri.

Par bonheur, quelques techniques existent pour contourner partiellement cette limitation et ainsi bénéficier d’un choix dynamique pour les rubriques de tri.

Dans cet article nous allons explorer l’une de ces techniques, elle ne concernera que les développeurs et utilisateurs de FileMaker (FM) sous environnement macOs, car elle est basée sur la technologie AppleScript (AS).

Exécuter du code AppleScript dans et depuis FileMaker Pro est possible depuis les toutes premières versions du logiciel, cela reste encore l’un de ses points forts sous macOS (même si, pour des raisons de compatibilité avec d’autres plate-formes, il est hélas souvent délaissé dans les projets professionnels).

Nous allons donc voir comment mettre rapidement en place un script de tri dynamique et générique, utilisable tel quel dans tous vos modèles liste, avec juste un zeste de code AppleScript.

Préparation

Pour commencer, de quoi allons nous avoir besoin ?

De très peu de choses : juste de deux rubriques globales de travail, qui peuvent être crées dans n’importe quelle table, mais qui trouveraient une place naturelle dans une table “Paramètres” (ou “Settings”).

Voici quelques explications à propos de ces deux rubriques (le suffixe “_g” est pour signaler leur portée globale) :

1. Tout d’abord, une rubrique de type texte, nommée par exemple “tri_rubrique_g”, qui contiendra le nom complet (table::rubrique) de la rubrique de tri ;
2. Ensuite, une rubrique de type nombre, nommée “tri_ordre_g” par exemple, qui contiendra une valeur booléenne indiquant l’ordre de tri : 0 = ordre descendant , 1 = ordre ascendant (pour s’assurer d’avoir toujours une valeur booléenne, on peut activer une entrée auto calculée avec le code suivant : ObtenirCommeBooleen ( Contenu ) ) ;

Le principe est simple : on passe le nom complet (table::rubrique) de la rubrique à trier en paramètre au script FileMaker de tri, si ce nom est identique à celui déjà mémorisé dans la rubrique globale “tri_rubrique_g”, alors on inverse tout simplement l’ordre de tri de la rubrique “tri_ordre_g”.

Si le nom passé en paramètre est différent de celui mémorisé, alors on mémorise ce nouveau nom dans la rubrique “tri_rubrique_g” et on règle la valeur de l’ordre de tri “tri_ordre_g” à 1 (tri ascendant par défaut).

Bon, pas trop compliqué jusqu’à là… voyons maintenant quel code AppleScript nous allons utiliser et comment l’exécuter…

AppleScript

FileMaker propose deux mécanismes pour exécuter un code AppleScript au sein d’un script avec l’action “Exécuter AppleScript” (présent dans la section “Divers” de la liste des actions) :

1. “AppleScript Calculé” : il s’agit d’y inscrire le code AppleScript comme si c’était du simple texte, FileMaker fera une interprétation puis une compilation à la volée du code avant son exécution, à chaque fois que le script FileMaker sera lancé. Dans ce mode, le passage de paramètres au code AppleScript est plutôt simple, il se fait par simple concaténation à l’intérieur du code ;
2. “AppleScript Natif” : il s’agit d’y inscrire le code AppleScript brut, qui sera compilé une seule fois à la validation du dialogue, puis il sera prêt à être exécuté tel-quel à chaque lancement du script FileMaker. Ici, le passage de paramètres au code AppleScript est un peu plus compliqué à mettre en place, il faudra par exemple prévoir des rubriques dédiées (nous ne verrons pas ce cas de figure ici).

Nous allons donc utiliser du code AppleScript calculé, plus simple à implémenter avec le passage des paramètres.

Plusieurs techniques sont possibles, comme :

1. Utiliser le code AppleScript directement dans le dialogue de l’action de script (solution la plus directe, souvent suffisante) ;
2. Placer le code AppleScript dans une rubrique globale et utiliser des balises pour être remplacées par les bons paramètres ;
3. Placer le code AppleScript dans une fonction personnalisée, puis utiliser les paramètres de la fonction FileMaker pour passer les paramètres à AppleScript.

Comme ici nous travaillons en local, la solution 2 avec la rubrique globale est celle que nous allons utiliser, plus simple d’accès pour notre démo. En revanche, pour une utilisation avec des fichiers hebergés dans un serveur, la solution 3 avec une fonction personnalisée semble la plus appropriée.

Dans tous les cas, le code AppleScript demeure le même, seule la technique du passage des paramètres diffère.

Voyons donc notre code AppleScript avec quelques commentaires (précédés de deux tirets “–“) pour bien comprendre le rôle de chaque instruction :

-- Structure 'try' de contrôle au cas où une erreur se produisait pendant l'exécution
try
 
    -- On récupère les valeurs de la rubrique et de l'ordre de tri dans des variables AS
    -- Pour ce faire, on utilise deux balises, délimitées par deux caractères dièse "##",
    -- qui seront remplacées par les valeurs issues des rubriques globales de travail

    -- Le nom complet (table::rubrique) de la rubrique de tri
    set sRubrique to "##tri_rubrique##"

    -- Le numéro booléen correspondant à l'ordre de tri
    set nOrdre to ##tri_ordre##
 
    -- On active FileMaker pour lancer le tri
    tell current application
 
        -- On récupère la bonne propriété d'ordre de tri à utiliser
        set pOrdre to contents of item (nOrdre + 1) of {descending, ascending}
 
        -- On lance le tri dans le modèle actif sur la bonne rubrique et le bon ordre
        sort current layout by field sRubrique in order pOrdre
 
    end tell

on error err_mssg number err_num
 
    -- On affiche un dialogue d'infos si une erreur se produit lors de l'exécution
    display dialog ("" & err_num & " : " & err_mssg)
end try

Les deux balises “##tri_rubrique##” et “##tri_ordre##” seront remplacées avec la fonction “Substituer()”, au sein du script FileMaker, par les valeurs issues des rubriques globales de travail “tri_rubrique_g” et “tri_ordre_g” respectivement.

Voyons maintenant de quoi il sera fait le code de notre script FileMaker…

Script FileMaker

Nous allons commencer par initialiser une variable “$rubrique” avec la valeur passée en paramètre au script. En effet, chaque bouton qui fera appel à ce script de tri, passera en paramètre le nom complet (table::rubrique) de la rubrique de tri.

Si le paramètre est vide, alors on annule le tri.

Comme expliqué plus haut, on défini l’ordre de tri selon que la valeur de la variable “$rubrique” et le contenu de la rubrique globale “tri_rubrique_g”, si elles sont identiques, alors on se contente d’inverser l’ordre de tri, sinon, on règle l’ordre de tri à la valeur par défaut = 1 (tri ascendant).

Ensuite on rensigne la rubrique globale “tri_rubrique_g” avec la variable “$rubrique”, on peut désormais faire le remplacement des balises “##” dans le code AppleScript avant de lancer son exécution.

Voici le code du script FileMaker complet avec les commentaires :

# Commandes de contrôle… comme d'hab…
Gestion erreurs [ Oui ]
Autor. annulation utilisateur [ Non ]
# 
# On récupère le paramètre de script et on efface tout éventuel espace de bord inutile
Définir variable [ $rubrique ; Valeur: SupprimerEspace ( Obtenir ( ParamètreScript ) ) ] 
# 
# Si une touche morte est enfoncée ou si la rubrique de tri est vide, alors on initialise les rubriques globales, on annule le tri et on active le premier enregistrement
Si [ ( Obtenir ( TouchesSpécialesActives ) ) Or ( EstVide ( $rubrique ) ) ] 
    Définir rubrique [ Settings::tri_rubrique_g ; "" ] 
    Définir rubrique [ Settings::tri_ordre_g ; 1 ] 
    Annuler tri des enreg.
    Afficher enreg/requête/page [ Premièr(e) ]
    Fin de script [ Résultat de texte: "Annulation du tri…" ] 
Fin de si
# 
# On défini et mémorise l'ordre de tri dans sa rubrique globale selon la rubrique de tri choisie : si même rubrique, alors on inverse l'ordre de tri, sinon on utilise la valeur par défaut 1 (ordre ascendant)
Définir rubrique [ Settings::tri_ordre_g ; ObtenirCommeBooleen ( Si ( EstEgal ( $rubrique ; Settings::tri_rubrique_g ) ; Not Settings::tri_ordre_g ; 1 ) ) ] 
# 
# On mémorise la nouvelle rubrique de tri choisie dans sa rubrique globale
Définir rubrique [ Settings::tri_rubrique_g ; $rubrique ] 
# 
# On valide tout ça…
Valider enreg./requêtes [ Avec boîte de dialogue: Non ] 
# 
# On initialise une variable avec le code AppleScript à exécuter, en remplaçant au passage les balises par les vraies valeurs de travail
Définir variable [ $applescript ; Valeur: Substituer ( 	Settings::tri_applescript_g ; 	[ "##tri_rubrique##" ; Settings::tri_rubrique_g ] ; 	[ "##tri_ordre##" ; Settings::tri_ordre_g ] ) ] 
# 
# On exécute le tri avec un AppleScript calculé
Exécuter AppleScript [ $applescript ] 
# 
# À la fin du tri, on active le premier enregistrement
Afficher enreg/requête/page [ Premièr(e) ]
# 
Fin de script [ Résultat de texte: "Tri effectué…" ] 
# 
# Code récupéré grâce au plugin MBS

Petite subtitilité ergonomique, nous avons ajouté un test sur les éventuelles touches spéciales actives lors du clic sur les boutons de tri, cela permet d’annuler le tri par simple clic d’un en-tête de colonne avec une touche morte enfoncée (commande, contrôle, option ou shift), cela évite de passer par un bouton dédié (même si cela reste toujours intéressant à proposer, surtout nécessaire si votre solution est utilisée avec FileMaker Go).

Voyons maintenant comment implémenter tout ceci dans notre modèle…

Implémantation

Nous allons donc construire un modèle liste, dans notre fichier de démo (communes de France), nous avons placé 4 rubriques, à savoir :

1. Code postal de la commune ;
2. Nom de la commune ;
3. Une date calculée aléatoirement entre les années 2000 et 2020 ;
4. Un numéro d’index aléatoire de 1 à 999.

Nous disposons donc, pour nos tests de tri, de deux rubriques de type texte (1 et 2) et de deux rubriques de type nombre (3 et 4).

Chaque en-tête de colonne sera donc un bouton qui lancera notre script FileMaker de tri, en passant comme paramètre le nom complet (table::rubrique) de la rubrique à trier (nous utilisons ici la fonction native ObtenirNomRubrique ( table::rubrique ) pour s’assurer d’avoir toujours le nom correct, quelque soient les modifications ultérieures).

Nous pouvons ajouter une mise en forme conditionnelle qui, en comparant le nom de la rubrique à trier avec celui existant dans la rubrique globale “tri_rubrique_g”, pourra changer l’aspect du bouton pour bien visualiser sur quelle colonne le tri a bien été effectué.

Nous pouvons également ajouter un indicateur de l’ordre de tri, dans notre fichier de démo nous utilisons la valeur de la rubrique globale “tri_ordre_g” comme affichage booléen avec deux caractères unicode représentant des flêches, une vers le haut “▲” (tri ascendant), l’autre vers le bas “▼” (tri descendant). L’affichage de cet indicateur sera géré par un masquage conditionnel sur le même principe, mais inversé, que celui de la mise en forme conditionnelle.

Voilà, nous avons pratiquement fini, il suffit d’ajouter des sous-récapitulatifs après tri sur les rubriques dont nous désirons faire des regroupements, tel qu’illustré par Tanguy dans le premier opus de cette mini série sur le tri.

Conclusion

AppleScript offre beaucoup de possibilités avec FileMaker, comme celle présentée ici, même si d’autres solutions de tri dynamiques existent pour ce type d’utilisations en mode liste, certains natives FileMaker.

En tout cas, n’hésitez-pas à décortiquer le fichier de démo en pièce jointe ci-dessous, pour bien visualiser et comprendre toutes les techniques décrites ici, vous pourrez ensuite nous faire part de toutes vos questions et remarques dans les commentaires ci-dessous.

Téléchargez le fichier de démo ici :  1MT_Tri_S02E01.fmp12

 

Intro

Dans nos solutions FileMaker, en général du moins, nous ne soucions pas particulièrement de la taille des données textuelles, en revanche, nous accordons un intérêt certain pour la taille des données “multimédia” à intégrer dans les bases de données au sein des rubriques de type conteneur ou même directement placées sur les modèles.

Les fichiers Pdf que nous pouvons générer à partir de FileMaker occupent une place importante dans cette problématique liée à la taille des données, notamment sur les solutions “métier”, où l’envoi et la sauvegarde des documents administratifs, commerciaux, contractuels, légaux, etc., ont une importance capitale.

Aujourd’hui, nous disposons de nombreuses techniques et solutions, plus ou moins efficaces, pour traiter les fichiers Pdf générés par FileMaker afin de réduire leur taille : plugins, lignes de commande, applications tierces et services en ligne. Malheureusement, la plupart de ces solutions sont souvent assez délicates à intégrer dans un flux de travail quand d’autres s’avèrent tout simplement complexes à implémenter dans nos projets.

Dans cet article je vous propose d’étudier ensemble, par des simples tests empiriques, quels sont les éléments de nos modèles qui, à coup sûr, influencent la taille des fichiers Pdf générés par FileMaker et, par conséquent, quelles solutions adopter pour les optimiser au mieux de manière totalement native, sans recourir à une quelconque technologie annexe.

L’étude exposée ici concerne plutôt les documents administratifs et de gestion, tels que les devis, factures, bons de commande, bons de livraisons, notes de frais, contrats, licences, condition générales, etc., c’est-à-dire, tous les documents où le texte occupe une place prépondérante par rapport aux éventuelles images existantes (généralement des logos ou pictos).

Tests et Solutions

Pour commencer, je vous invite à télécharger le fichier « Optimisation-Pdf.fmp12 » qui se trouve à la fin de cet article. Il s’agit tout simplement d’une base FileMaker issue des ses solutions de démarrage (version 14), à savoir, la solution “Facturation”, qui dispose d’un modèle de facture que nous allons utiliser et modifier pour réaliser tous nos tests.

Tout ce que nous avons à faire, donc, c’est de travailler nos modèles d’impression, ou concevoir des modèles spécialement dédiés aux Pdf, de manière à les simplifier et à les alléger de tout ce qui pourrait impacter la taille des Pdf générés. Trois aspects sont particulièrement à considérer (par ordre croissant d’importance) :

1. Les images
2. La composition (la mise en page des modèles)
3. Les textes

1. Les images

Et oui, ça peut paraître bizarre (voire paradoxal), mais les images ce sont les éléments qui, finalement, posent le moins de problèmes lors de la création des fichiers Pdf avec FileMaker.

Ceci tout simplement parce que, hélas, FileMaker ne dispose d’aucune fonctionnalité native pour travailler directement sur les images, aussi bien lorsqu’elles sont intégrées dans des rubriques de type conteneur que lorsqu’elles sont placées sur les modèles.

Même si, selon mes observations, il semblerait que le moteur de fabrication des Pdf utilisé par FileMaker tente d’optimiser les images, les résultats dépendent évidemment de la nature des images déjà présentes, il convient donc de les traiter en amont, avec des logiciels dédiés, afin d’optimiser leurs poids avec différentes manipulations, comme par exemple :

• en les redimensionnant aux dimensions exactes requises sur les modèles ;
• en supprimant les espaces, marges et bords inutiles ;
• en réduisant le nombre de couleurs ;
• en les passant en niveaux de gris si la couleur n’est pas nécessaire ;
• en adoptant les bons formats de fichiers compatibles FileMaker : Jpeg, Png, Gif, etc. ;
• en utilisant les taux de compression qui offrent le meilleur compromis poids/qualité ;
• etc.

Pour illustrer cette optimisation, vous trouverez dans le fichier de test disponible à la fin de l’article, une icône en guise de logo placée dans les modèles d’impression. Le poids du fichier original de cette image, en couleurs, était de pratiquement 3 Ko (2 837 octets), après une optimisation dans un logiciel de traitement d’images, l’icône intégrée (en niveaux de gris) pesait moins de 1 Ko (879 octets).

Au final, ce qu’il faut retenir, c’est qu’une fois les images intégrées dans FileMaker, on ne pourra plus rien faire sur place, de manière native, pour réduire leurs poids respectifs afin d’optimiser nos Pdf, ce travail doit donc être fait en amont.

2. La composition

L’idée est d’optimiser la composition des nos modèles d’impression ou dédiés aux Pdf, avec comme but d’obtenir des mises en pages les plus simples possibles, qui nous permettront d’économiser encore quelques dizaines ou centaines d’octets.

Alors, disons-le tout de suite, ne vous attendez pas à réaliser des gains spectaculaires entre une composition “normale” et une mise en page optimisée, mais aucune économie étant à négliger, autant adopter les bonnes pratiques dès le début de chaque projet.

Évidemment, si vous avez déjà une multitude de modèles déjà réalisés dans vos solutions, la simplification de leur mise en page vous demandera de nombreuses heures de travail pour une optimisation assez minime de vos Pdf au final, je ne vous conseille donc pas de vous lancer dans de telles manipulations si peu rentables.

En revanche, pour tout nouveau projet, vous pouvez suivre les recommendations suivantes (sans ordre particulier d’importance) afin de soigner la mise en page de vos modèles d’impression et ainsi optimiser vos Pdf :

• préférez les rubriques de fusion aux simples rubriques lorsque c’est possible ;
• évitez autant que possible de multiplier les objets, simplifiez vos compositions ;
• évitez également les éléments superposés quand ce n’est pas nécessaire ;
• évitez les effets sur les objets quand ce n’est pas utile : ombres, contours pointillés, bords arrondis, dégradés, transparences, etc.
• tentez de privilégier les attributs de paragraphes pour gérer les alignements et espacements des textes dans les blocs ;
• lorsqu’il faut matérialiser des tableaux avec des colonnes de données, tentez d’utiliser la technique des tabulations pour séparer les données ;
• évitez les couleurs quand ce n’est pas nécessaire, préférez l’utilisation des niveaux de gris pour gérer la mise en valeurs des objets et des textes.

Pour avoir une idée de ce qu’on obtient avec ce type d’optimisation, je vous invite à afficher côte-à-côte, en mode modèle bien-sûr, les modèles “Imprimer/envoyer facturation” et “Pdf-4-Mono-Test” du fichier de test présent à la fin de cet article.

Encore une fois, j’insiste, les gains de poids obtenus avec ces mises en pages simplifiées sont très modestes et ne justifient nullement de reprendre tous vos modèles existants, utilisez plutôt ces techniques pour vos nouvelles réalisations.

3. Les textes

Voilà le chapitre le plus intéressant car c’est en manipulant les textes que nous allons obtenir les optimisations les plus importantes sur nos Pdf.

De nombreux aspects sont à considérer, comme le nombre de polices des caractères utilisés, les choix des ces polices des caractères, la présence des enrichissements typographiques (gras, italique, etc.) et le nombre de caractères différents affichés (ce qui est difficilement maîtrisable). Le principe d’optimisation est très simple (par ordre croissant d’importance) :

– moins il y a de caractères différents affichés,
– moins il y a d’enrichissements typographiques appliqués,
– moins il y a de polices de caractères utilisées et mieux elles sont choisies,
= plus l’optimisation sera importante et donc la taille du Pdf réduite.

Les conseils à suivre sont donc évidents :

• limiter autant que possible la quantité de caractère différents et l’utilisation des caractères hors alphabet classique (pas toujours possible, mais à tenir en compte au besoin) ;
• éviter les enrichissements typographiques quand ils ne sont pas vraiment nécessaires : gras, italique, souligné, petites majuscules, etc., préférez jouer avec la taille des textes ;
• éviter de multiplier les polices des caractères, une seule police de caractères peut souvent suffire à obtenir une mise en page claire et lisible ;
• bien choisir sa police des caractères : suivant la police utilisée, la taille du Pdf peut varier quasiment du simple au triple (imaginez avec plusieurs polices).

Concernant l’impact que peut avoir l’utilisation des caractères différents, voici un simple petit test, que vous pouvez retrouver dans l’archive “Pdf-Caracteres.zip” à la fin de l’article, composé de 5 fichiers Pdf dont voici le détail :

• Fichier “_vide.pdf” : Pdf vide (aucun texte, aucune police de caractères) = 5 Ko (5 110 octets) ;
• Fichier “a.pdf” : juste une lettre “a” avec la police “Arial” = 42 Ko (42 422 octets) ;
• Fichier “aaaaaa_26.pdf” : 26 lettres “a” avec la police “Arial” = 42 Ko (42 454 octets) ;
• Fichier “alphabet_26.pdf” : alphabet de 26 caractères minuscules avec la police “Arial” = 52 Ko (51 586 octets) ;
• Fichier “alphabet_ascii.pdf” : alphabet ASCII de 224 caractères avec la police “Arial” = 119 Ko (118 610 octets) ;

Ce test nous montre clairement que, pour chaque police de caractères utilisée, le nombre de caractères différents présents dans le modèle influence la taille finale des Pdf. Malheureusement, mis à part une bonne information auprès des utilisateurs, il n’y a pas vraiment de technique efficace pour limiter le nombre de caractères différents sans risquer de dénaturer les données.

Dans le fichier FileMaker de tests, vous trouverez, dans la zone de navigation en haut du modèle “Détails facturation”, un petit bouton-popover “PDF” qui vous permettra de générer des fichiers Pdf à partir de différents modèles, tous issus du modèle d’impression original, mais qui ont été modifiés afin de pouvoir visualiser la taille des Pdf produits en changeant un ou plusieurs aspects de cette optimisation des textes.

Deux options possibles :

1. Exemples : permet de générer des Pdf d’exemples, cela produit 7 fichiers Pdf pour illustrer l’impact important qu’ont les polices des caractères et le formatage des textes sur la taille des Pdf ;
2. Polices : permet de générer des Pdf selon une police de caractères choisie, cela produit 3 fichiers Pdf pour comparer leurs tailles respectives avec les Pdf analogues d’une autre police de caractères.

Le choix des polices de caractères de ces tests est volontairement limité à celles qui sont les plus utilisées et compatibles avec les plate-formes Mac et Pc. D’autre part, vous trouverez dans ce panneau popover un petit bouton d’aide “?” vous donnant accès à une description du nommage choisi pour les fichiers Pdf générés et leurs signification.

Pour que vous puissiez avoir une idée de la taille des différents Pdf générés par l’option “Polices”, voici un tableau comparatif qui présente assez bien les polices des caractères les plus légères à privilégier dans vos réalisations :

Polices de caractères	Avec 1	Sans 2	Test 3
Arial	139 Ko	63 Ko	62 Ko
ComicSans	51 Ko	34 Ko	33 Ko
Courrier	71 Ko	36 Ko	34 Ko
Georgia	83 Ko	40 Ko	39 Ko
Helvetica	96 Ko	42 Ko	41 Ko
Lucida	89 Ko	52 Ko	51 Ko
Palatino	80 Ko	39 Ko	37 Ko
Tahoma	88 Ko	52 Ko	51 Ko
Times	87 Ko	40 Ko	38 Ko
Trebuchet	60 Ko	32 Ko	31 Ko
Verdana	64 Ko	32 Ko	31 Ko

1. Avec = modèle PDF avec des textes qui ont des enrichissements typographiques (gras ou italique).
2. Sans = modèle PDF avec des textes qui n’ont aucun enrichissement typographiques (gras ou italique).
3. Test = modèle PDF de test avec composition simplifiée et textes sans aucun enrichissement typographiques.

Nous pouvons voir dans ce tableau que la police de caractères “Arial” est la plus “encombrante” dans tous les cas, alors que certaines polices, suivant l’application des formatages ou pas, produisent des Pdf extrêment légers avec des gains très intéressants, il convient donc de bien les choisir dans nos modèles pour une meilleure optimisation de nos Pdf.

Attention tout-de-même, ces valeurs sont rélatives aux polices présentes dans chaque système d’exploitation, dès lors, un modèle réalisé avec la police “Arial”, par exemple, peut produire des Pdf de tailles très différentes d’un ordinateur à un autre, il est donc important d’effectuer des tests lors du développement mais aussi, surtout, chez l’utilisateur final.

Conclusion

Nous avons vu que la taille des Pdf est directement liée aux contenus des nos modèles d’impression et à leur formatage, alors, bien qu’il soit difficile de tout maîtriser, si nous observons les trois préceptes suivants, nous allons pouvoir obtenir nativement des fichiers Pdf de taille très réduite, ce qui n’empêche nullement, au besoin, d’opérer d’autres optimisations avec des technologies annexes :

• Optimiser les images avant de les intégrer dans nos solutions ;
• Simplifier au maximum la mise en page de nos modèles ;
• Utiliser le minimum de polices de caractères et appliquer le minimum de formatages (idéalement : une seule police de caractères et aucun formatage typographique).

Voici le fichier FileMaker de tests à télécharger :  Optimisation-Pdf.fmp12

Voici l’archive avec les tests des caractères :  Pdf-Caracteres.zip

Merci pour votre lecture, toutes remarques, commentaires et questions sont les bienvenues.