Il vient de zmarkdown. C’est zmarkdown qui génère le latex, le latex vient de zmarkdown. Zmarkdown prend du markdown en entrée et sort soit de l’HTML soit du latex.
Le but de tout ça, zmarkdown + template latex, c’est qu’on puisse générer du latex qui corresponde au markdown, puis compiler le tout vers un PDF. Zmarkdown, je viens d’en donner l’exemple au message précédent, a un block "secret" avec un titre optionnel.
Si le template latex ne gère pas les titres des spoilers, c’est un bug dans le template latex.
Il vient de zmarkdown. C’est zmarkdown qui génère le latex, le latex vient de zmarkdown. Zmarkdown prend du markdown en entrée et sort soit de l’HTML soit du latex.
Le but de tout ça, zmarkdown + template latex, c’est qu’on puisse générer du latex qui corresponde au markdown, puis compiler le tout vers un PDF. Zmarkdown, je viens d’en donner l’exemple au message précédent, a un block "secret" avec un titre optionnel.
Si le template latex ne gère pas les titres des spoilers, c’est un bug dans le template latex.
Un bug peut-être pas, mais une fonctionnalité pas encore implémenté.
Je sais très bien ce que fait zmarkdown, ce que je ne comprenais pas c’est pourquoi zmarkdown génère un Spoiler avec un titre optionnel mais que coté latex l’environnement spoiler ne prennais aucun paramètre optionnel.
J’ai maintenant ma réponse, merci @cepus
Du coup il s’agit soit d’un oubli, soit d’un bug coté template.
J’ai compris pourquoi on refuse l’upload de svg car quand on y accède directement le js s’exécute.
Par contre, je ne comprend pas pour ce qui est de l’affichage de svg dans une balise img, le JS n’est pas traité. Alors pourquoi n’accepte-t-on pas les .svg ?
<imgsrc="/test/circle88.svg">
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"><svgversion="1.1"xmlns="http://www.w3.org/2000/svg"><circlecx="250"cy="250"r="500"fill="red" /><scripttype="text/javascript"><![CDATA[
alert("lol");
var KEY = { w:87, a:65, s:83, d:68 };
var moveSpeed = 50;
var circle = document.getElementsByTagName("circle")[0];
var x = circle.getAttribute('cx')*1,
y = circle.getAttribute('cy')*1;
document.documentElement.addEventListener('keydown',function(evt){
switch (evt.keyCode){
case KEY.w:
circle.setAttribute('cy',y-=moveSpeed);
// Alternatively:// circle.cy.baseVal.value = (y-=moveSpeed);break;
case KEY.s:
circle.setAttribute('cy',y+=moveSpeed);
break;
case KEY.a:
circle.setAttribute('cx',x-=moveSpeed);
break;
case KEY.d:
circle.setAttribute('cx',x+=moveSpeed);
break;
}
},false);
]]></script></svg>
la balise image accepte les SVG (utilise ton code, ça marche), c’est la galerie qui ne les accepte pas. On verra dans le futur si on peut les mettre néanmoins.
AH… J’ai du me tromper en recopiant le lien alors.
EDIT :
la balise image accepte les SVG (utilise ton code, ça marche), c’est la galerie qui ne les accepte pas. On verra dans le futur si on peut les mettre néanmoins.
La façon de faire que j’utilisais pour citer la sélection (parser le HTML en markdown), était à l’origine un code PHP qui convertissait le HTML en array pour vérifier que les éléments ne contiennent pas de JS (on enlève les attributs ou tags qui ne sont pas dans la whitelist) et ainsi on pouvait accepter du HTML d’une saisie d’un utilisateur.
Ou sinon faire comme github et modifier format en text/plain et dans le src mettre la base64 au lieu du lien direct. Fonctionnement : une requête récupère l’image data-image via une requête XHR et le script retourne le base64 dans l’attr src du tag img.
L’option générer une fonte est vraiment impossible ? Apparemment il y a des outils en ligne qui permettent de faire ça, ça serait une solution bien plus heureuse àmha. Ou alors, il y a ça.
La licence de la font autorise-t-elle de modifier la font actuelle ? Comment fait-on pour les animations ? On ne pourra pas ou on devra faire autrement.
Le temps de chargement sera-t-il viable ? Aura-t-on la même qualité ? La conversion en svg -> font va-t-elle être conforme ? De combien de temps le build va être rallongé ?
Est-ce vraiment utile ?
Ensuite si on fait une font uniquement pour les smileys via un fichier CSS et une balise HTML, on se complique la vie alors qu’on peut simplement utiliser une balise IMG.
Les fontes sont faites pour représenter des caractères. Markdown est fait pour baliser sématiquement du texte. Les mélanger est, à mon avis, une idée assez moyenne, et notre Markdown en fait déjà beaucoup en corrigeant la typographie.
Je ne comprends pas pourquoi le temps de chargement serait ralongé. Dans le pire des cas, il y a la fonte fallback qui affichera les smileys moins jolis avant que ta fonte soit chargée. Dans le cas d’une image, il y aura juste un petit carré laid. Je ne comprends pas la question de la qualité.
De plus, les images ne seraient (très probablement) pas alignée correctement sur la grille.
Je trouve moins grave d’augmenter le temps de build que le temps de rendu, mais c’est mon avis personnel.
La question de la license est, à mon avis, la même que si tu l’intègres en SVG.
Pour les animations, c’est en effet triste. À la rigueur, JavaScript peut faire de la magie (dés)activable.
À propos de FontAwesome, la question est, toujours à mon avis, différente. Son but n’est pas de s’intégrer comme du texte, mais comme éléments d’interface. Ca semble assez raisonable de ne pas vouloir faire des interfaces basées uniquement sur des caractères (qu’il faut standardiser), mais cela dit, je ne sais pas quelle est leur motivation exacte ici.
Bref, KISS.
Edit: sinon, pour remplacer (à nouveau) les smileys existants, ça se passe du côté de zds-site, je crois.
Petit souci avec les acronymes. Je sais pas comment expliqué alors voici un texte pour reproduire :
Comme on peut le voir ici, zmd bug sur ZdS si je sépare les définitions des abbrévations avec un espace à la fin, comme dans ce test.
*[zmd]: zmarkdown
*[ZdS]: Zeste de Savoir
Voici le même texte ci-dessous. On voit que la définition de l’abbréviation "ZdS" tout à la fin s’affiche au lieu d’être invisible. Le bug ne se produit pas si je ne met pas d’espaces vides entre les définitions.
Comme on peut le voir ici, zmd bug sur ZdS si je sépare les définitions des abbrévations avec un espace à la fin, comme dans ce test.
@Eskimon, Il semblerai du coup qu’il n’autorise pas de ligne vides entre les définitions des abréviations d’une même page. Est-ce que ça a un réel intérêt de séparé les définitions d’abréviations par des lignes vides ?
Comme on peut le voir ici, zmd bug sur ZdS si je sépare les définitions des abbrévations avec un espace à la fin, comme dans ce test.
Une ligne en plein milieu.
Si ce ceci (ci-dessous) est possible, c’est visiblement un bug.
Comme on peut le voir ici, zmd bug sur ZdS si je sépare les définitions des abbrévations avec un espace à la fin, comme dans ce test.
*[zmd]: zmarkdown
Une ligne en plein milieu.
*[ZdS]: Zeste de Savoir
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
ou on devra faire autrement.
