Pfffffffffffff Ça plante, ça plante, ça plante

Bonjour,

Punaise je fais un seul document de 30 pages par an avec beaucoup de photos, en me disant que la dernière version (4.1.4.2) aura corrigé tous ces plantages à répétition, et c'est pire que l'an dernier (avec la 3.6 ?).
Toutes liées (d'ailleurs pourquoi faut-il recocher à chaque fois, ne pourrait-il pas garder la mémoire de mon choix ?).

Options mémoire :
256 Mo pour LO
12 Mo par objet
Cache pour 100 objets

Windows 7-64 bits, RAM 4 Go
Aucun plantage dans d'autres logiciels

(Par ailleurs j'utilise LibreOffice au quotidien pour du texte et quelques illustrations et j'en suis satisfait).

A chaque fois c'est à l'enregistrement que ça plante.
Et pourtant je fais régulièrement un Enregistrer sous... en espérant repartir sur une bonne base.
10 Go libres sur le HD, en local.

Comment identifier les images non liées ?
Y a-t-il une option "Ne pas afficher les images liées" ?

Merci

Bonjour

Le conseil pour les documents comprenant plusieurs images est de les
"travailler" avant intégration (taille écran pour éviter de rogner, taille
d'impression, résolution, nombre de couleurs...) en adaptant les
paramètres à la destination du document (la qualité photo n'est pas
toujours indispensable).

"Stéphane G." wrote

Comment identifier les images non liées ?

Affichage > Navigateur (F5)
"Déplier" l'entrée Image
L'url des images liées est affiché en info-bulle

<http://nabble.documentfoundation.org/file/n4089589/Navigateur.png>

Cordialement
Pierre-Yves

Existe-t-il un mode Debug avec un Log qui pourrait me faire tracer ce qui fait planter à l'enregistrement... ?
Mon fichier fait 37 ko !!!

Suite...

&quot;Stéphane G.&quot; wrote

Existe-t-il un mode Debug avec un Log qui pourrait me faire tracer ce
qui fait planter à l'enregistrement... ?

Infos à suivre à partir d'ici :

http://nabble.documentfoundation.org/Premiere-Release-Candidate-de-LibreOffice-4-2-0-disponible-pour-vos-tests-tp4089094p4089164.html

Cordialement
Pierre-Yves

Merci.

Je viens d'installer la 4.2.
Ouvert mon fichier, enregistrer sous... nouvelle version.
A enregistré très vite comparé à la 4.1, et le fichier est réellement créé.
Je me croyais sorti d'affaire mais finalement une petite boîte de dialogue "Fatal Error" avec le message "Bad allocation".

Donc je vais essayer de me palucher ce debug dans la semaine....

Bon Noël à vous !

ET plantage de l'appli, exit.

Ah ben maintenant avec la 4.2, Insertion | Image | A partir d'un fichier...
Selection d'une .jpg

-> Message : "Impossible de trouver le filtre d'image"

Suite...

&quot;Stéphane G.&quot; wrote

Ah ben maintenant avec la 4.2, Insertion | Image | A partir d'un
fichier...
Selection d'une .jpg
-> Message : "Impossible de trouver le filtre d'image"

Je ne reproduis pas tous ces problèmes. As-tu essayé de renommer
ton profil comme expliqué ici
https://wiki.documentfoundation.org/FR/FAQ/Generale/110 ?

Pierre-Yves

Bonjour Stéphane,

pourrais-tu lancer un procmon.exe (disponible sur le site technet de
microsoft) juste avant de reproduire ton problème,
dès que ton problème est reproduis, stoppe procmon (icône : petite loupe).
et enregistre le log (tous les événements), comprime le en ZIP (car souvent
très lourd) et envoie le moi pour analyse.
Peut-être que je verrais ce qui cloche ?

je suppose que tu as essayé de nettoyer ton profil ? est-ce que ton doc est
confidentiel, sinon, je pourrais tester sur ma machine pour voir...

Yves

Bonjour,

J'arrive à reproduire systématiquement.
- Windows 7-64 + 4Go RAM
- Effacé tout mon profil
- Relancé LO 4.2
- Options mémoire de base :
   . Annuler 100 opérations
   . 20 Mo pour LO
   . 5.2 Mo par objet
   . cache pour 20 objets insérés
- J'ouvre mon doc
   . 48 ko
   . Environ 32 images liées, dont la plupart à 2000-2500 pixels de large
- Je fais défiler les pages en laissant les images bien s'afficher
- Arrivé à environ 30ème image, plantage net, proposition de récupération
(ProcMon->logfile01)

Maintenant
- je rouvre LO,
- annule la restauration,
- rouvre mon fichier sans faire défiler les images,
- enregistrer sous... nouveau nom de fichier
- il enregistre
- je fais défiler les pages,
- et sans arriver aussi loin que précédemment : MessageBox "Bad allocation"

Et il semble que si ProcMon est lancé, ce dernier dialogue n'apparaît pas mais :
- Les 2 dernières images de la dernière page n'affichent que le cadre avec nom de fichier et scintillent l'une après l'autre, comme si l'image ne pouvait être affichée.
(ProcMon->logfile02)

C'est bien le nombre d'images affichées qui fait planter, car en chargeant le doc, si je fais défiler rapidement sans afficher toutes les images, je peux très bien afficher les 2 dernières du doc; puis en remontant le doc en affichant tout, ça replante.

En augmentant les paramètres de mémoire j'arrive à retarder le plantage mais je n'arrive pas à travailler.

Mes images font 9cm de large sur papier et à 600dpi ça fait à peu près leurs 2300 points de large. Donc je ne compte pas réduire les images.

Je suis en train de téléverser mon doc avec images des 240 Mo pour que vous essayiez.
J'ai fait mes procmon, à téléverser ensuite.

Donc j'envoie ça en mail privé.

Merci

Stéphane

Bonjour,

J'arrive à reproduire systématiquement.
- Windows 7-64 + 4Go RAM
- Effacé tout mon profil
- Relancé LO 4.2
- Options mémoire de base :
   . Annuler 100 opérations
   . 20 Mo pour LO
   . 5.2 Mo par objet
   . cache pour 20 objets insérés
- J'ouvre mon doc
   . 48 ko
   . Environ 32 images liées, dont la plupart à 2000-2500 pixels de large
- Je fais défiler les pages en laissant les images bien s'afficher
- Arrivé à environ 30ème image, plantage net, proposition de récupération
(ProcMon->logfile01)

une image de 2000x2500 fait 46Mo pour l'ordinateur qui doit l'afficher.
Je te laisse le soin de calculer ce que tu demandes avec 32 images !
Si les images doivent réellement avoir cette taille, il faut utiliser un logiciel genre scribus qui travaille sur un aperçu.
Gérard

Bonjour,

  . Environ 32 images liées, dont la plupart à 2000-2500 pixels de large

D'accord avec Gérard.

[...]
Mes images font 9cm de large sur papier et à 600dpi ça fait à peu près
leurs 2300 points de large. Donc je ne compte pas réduire les images.

Sauf besoin très spécifique (lequel ?), 600 dpi c'est trop pour une
impression sur 9 cm. 300 suffiraient, je pense. Donc je t'encourage moi
aussi à passer en mode Jivaro.

Bonjour,

une image de 2000x2500 fait 46Mo pour l'ordinateur qui doit l'afficher.
Je te laisse le soin de calculer ce que tu demandes avec 32 images !
Si les images doivent réellement avoir cette taille, il faut utiliser un
logiciel genre scribus qui travaille sur un aperçu.
Gérard

Père Noël !
Apporte-moi un mode Aperçu des images pour Libre Office ! :wink:

Quoi qu'il en soit, qu'il ne m'affiche pas les images tout de suite, ou que les images de la page active, ça ne me dérangerait pas, le problème est que LibreOffice plante quand il y a trop d'images, au lieu de squizzer l'affichage.

Bonne journée

Bonjour,

une image de 2000x2500 fait 46Mo pour l'ordinateur qui doit l'afficher.
Je te laisse le soin de calculer ce que tu demandes avec 32 images !
Si les images doivent réellement avoir cette taille, il faut utiliser un
logiciel genre scribus qui travaille sur un aperçu.
Gérard

Père Noël !
Apporte-moi un mode Aperçu des images pour Libre Office ! :wink:

Bonjour,

Cela se fait très bien avec une capture d'écran ! (par zone sélectionnée)

Cordialement.

Michel

Quelle ironie! C'est EXACTEMENT le même problème que moi il y a un an et demi: des images qui ne pouvaient pas être réduites puisqu'on parlait de graphiques de précision, et que cependant LibreOffice/OpenOffice était incapable de gérer correctement sans planter, ni afficher progressivement les images de la page active seule, en déchargeant celles qui n'étaient pas affichées, ce que MS Word savait faire, lourdement mais sans planter. Un essai par document-maître ne résolvait rien, vu qu'il chargeait tout en une seule manœuvre.

Finalement, de peine et de misère, sur des machines surpuissantes, j'ai réussi à terminer le document, en me laissant le goût amer que LibreOffice n'est pas prêt pour le travail lourd, peu important dans quel sens on choisit d'organiser son document.

P.S.: On écrit «squeezer».

Bonjour,

C'est bien le constat que j'avais fait il y a déjà quelques années.
Triste de voir qu'une fonctionnalité qui me paraît si basique ne soit toujours pas prise en compte.
Je suis convaincu qu'en plus ce serait un gain de performance pour l'application LibreOffice, puisque le travail sur un aperçu permet d'allouer bien moins de mémoire.

Finalement, je suis passé sous Scribus selon les conseils de Gérard.
Un peu dérouté au départ, mais j'ai été agréablement surpris de trouver un scriting en Python qui va me permettre d'automatiser mon album photo.

Autre bonne surprise de Scribus, lorsque l'on définit une bordure sur une image (sur son "cadre"), cela ne change pas les dimensions générales de l'objet, et les alignements sont conservés quel que soit l'épaisseur du trait de bordure.

Bonjour á la liste,

à la décharge de LibO, rares sont ceux qui travaillent sur de très lourds documents, donc ce n'est peut-être pas une priorité. Cependant, les documents ne "naissent" pas lourds, ils le deviennent à force d'ajouts, à un moment où il est déjà souvent trop tard pour faire une transition en douceur vers MS Office. Si l'optimisation de LibO n'est pas prioritaire, à tout le moins un avertissement de ralentissements importants et d'instabilité possible devrait être affichée au chargement.

En même temps, comme usager simple, je me demande ce qui est prioritaire chez LibO alors que l'ergonomie est un peu dépassée, qu'il n'y a pas d'automatisation liée aux styles (alors que tous les gens très expérimentés répètent inlassablement de toujours commencer par un style, et éviter les mises en formes manuelles, ce qui est contre-intuitif et contre-productif pour les documents qui ne verront le jour qu'en un seul exemplaire), que sa prise en charge de lourds documents est, disons-le, déficiente, tout comme sa compatibilité avec les formats en -X de MS Office, ou l'absence de modèles aussi nombreux que ceux de son concurrent non-libre, ou l'état toujours rudimentaire de sa partie base de données. Apple a trouvé un juste milieu pour son Pages, qui est autant un traitement de texte qu'un logiciel de mise en page et publication. Hélas il est propriétaire, et assez peu intercompatible. Disons que c'est assez flou pour l'utilisateur final et que la méthode de développement surnommée "release few, release often" pourrait ne pas être adaptée à un logiciel soutenu par une petite équipe qui n'a pas les moyens des grosses compagnies.

Concernant ton expérience avec Scribus, est-ce que la transition a demandé de réécrire tout le document pour ce logiciel? Ou avec une prise en charge directe du format OpenDocument?

Bonjour,

Concernant ton expérience avec Scribus, est-ce que la transition a

> demandé de réécrire tout le document pour ce logiciel?
> Ou avec une prise en charge directe du format OpenDocument?

J'ai tout réécrit de zéro car choisi d'automatiser à fond en créant un script Scribus-Python pour aller chercher les photos dans un dossier et ses sous-dossiers et aligner automatiquement les images sur le Doc à la Flicker.

Je n'ai en fait réalisé que peu de mise en page de texte (à venir) sous scribus, seulement lourdement travaillé sur les photos.