Break-inside: avoid

Personnaliser SCENARIstyler
1

Bonjour,

J’adapte le skin guide pdf Dokiel à la charte graphique de mon entreprise et je suis confronté à une « anomalie » lors de la génération du PDF:

  • No valid break point found. (page 4)

L’élément qui déclenche cette anomalie (qui ne semble pas avoir d’impact réel sur la publication en elle même) est cet élément du css que j’ai introduit pour éviter que les écrans soient découpés sur plusieurs pages:

.screen{
  break-inside: avoid;
}

Quelqu’un saurait ce que cette anomalie signifie et comment l’éviter ?

2

Bonjour et bienvenu !

Un bloc screen peut est très long, il y a l’image de l’écran puis la description des zones.
Il est assez courant que l’ensemble puissent prendre plus qu’une page en hauteur.
Hos ici vous lui demandez de ne pas découper un screen sur deux page alors que c’est peut-être juste impossible, Dokiel panique !

Je vous conseil de retenter en utilisant une directive CSS dédié Postscriptum (le moteur de rendu PDF utilisé) et pas une directive CSS standard :

.screen {
    break-inside: -ps-avoid-if-below(10cm);
}

Ici on évite de découper les « petit » screen mais on permet de découper les plus gros.

1 « J'aime »
3

Merci pour la réponse rapide et instructive, cela fonctionne maintenant sans anomalie !

Y a-t-il un moyen d’inspecter le contenu du rendu pdf de la même façon que l’on peut inspecter le rendu web avec les outils de développement web ? Cela m’aiderai à trouver les nom des classes sur lesquel agir pour adapter ma mise en page.

4

Bonjour,

Oui en travaillant en local, vous pouvez « révéler » la publication de test et ouvrir le fichier index.html

:point_right: Changer taille du logo sur PDF - #2 par mid

Mickaël

5

Pour commencer, il faut travailler en local, debuger un skin Print en client-serveur est presque impossible.

Je conseille donc :

Une fois le skin posé et les tests commencés vous pouvez alors révéler la publication et soit utiliser un navigateur pour ouvrir le fichier index, soit utiliser l’application Postscriptum qui vous permet de voir exactement la mise en forme finale.

6

Merci, je viens de faire la manipulation, c’est un peu contraignant, si je comprends bien il faut (une fois l’installation faite comme décrite par Sam):

  • exporter l’atelier ScenariStyler + l’atelier Dokiel depuis la version serveur
  • les importer sur la version Desktop
  • faire les modification
  • ré-exporter dans la version serveur

Ça fait beaucoup de manipulations c’est dommage qu’il n’y ai pas un lien direct vers le index.html dans la version serveur (mais je suppose qu’il y a des contraintes techniques).

En tout cas merci de m’avoir fait utiliser Postscriptum, je n’avais pas compris son intérêt la première fois que je l’avais identifié sur la page de ScenariStyler.

PS: du coup il n’y a peut-être aucun intérêt a avoir l’Atelier ScenariStyler sur la version serveur ? Peut-on facilement installer un skin sans cet atelier ?

7

Pour moi concevoir un skin en pur serveur n’a de sens que dans un contexte de skin formulaire ou on ne change que quelques couleurs.

Personnellement, en temps de développeur, travailler en local est un must dès qu’on développe un skin complexe :

  • debug de Javascript / CSS bien plus rapide directement dans une génération puis on reporte dans styler quand ça marche
  • pouvoir commiter les sources du skin dans un repos git pour pouvoir suivre son évolution
  • le debug d’un skin PDF le requiert

Il est nullement utile de reposter les sources du skin sur un server, compilez simplement le skinpack en local est installer-le sur le serveur.

Tous les skins proposés par scenari.software comme Opale Dys, Sunrise, Daylight son développés el local.

8

1 « J'aime »