<foo> simply produces <foo>in the text).
<URL: http://somewhere.tld/ >,
and it will be automatically made into a link.
(Do not try any other way or it might count as an attempt to spam.)mailto: URI,
e.g. mailto:my.email@somewhere.tld,
if you do not have a genuine Web site).
Lionel (2008-08-07T12:16:09Z)
Est-ce que tu comptes publier le fichier XML source et le schéma que tu utilises?
Personellement, j'utilise maintenant C#/XLinq pour le triturage de XML. (Je crois que Mono 2 supportera tout ce qu'il faut, et est annoncé pour septembre). Cela donne des trucs comme ça :
XElement sitemap = cfg.Root.Elements("sitemap").First();
ul_data = (
from page in sitemap.Descendants("page")
select new XElement(htmlns + "li",
new XElement(htmlns + "a",
new XAttribute("href", page.Attribute("url").Value),
page.Attribute("title").Value
)
)
).ToList();
.
Fork (2008-08-07T08:46:31Z)
D'accord, merci d'avoir éclairé ma lanterne.
tartaglia (2008-08-07T08:00:43Z)
l'appendice et les annexes, en anatomie, c'est différent, les annexes sont utiles même si elles sont de taille plus modeste que l'organe central auquel elles sont… annexées.
Mouton (2008-08-07T06:12:26Z)
Quand la complexité de Kolmogorov ton makefile dépasse celle du livre, tu le publies aussi ? J'imagine que tu as pris les devants, et que ton makefile est rédigé en xml.
Ruxor (2008-08-07T02:14:23Z)
Je crois que la convention française traditionnelle est de mettre la table des matières à la fin, en effet, mais il n'y a pas de raison particulière de suivre cette convention (je trouve quand même beaucoup plus commode de mettre la table des matières au début et l'index à la fin !). Quant à la distinction entre sommaire et table des matières, je dirais qu'il n'y en a pas, sinon qu'on utilise peut-être plus volontiers le terme de sommaire quand il y a un bref résumé des chapitres (et pas juste le titre), mais je ne suis pas sûr que ce soit vraiment une différence dans l'usage du mot.
Quant à appendice, c'est un terme plus général qu'annexe, mais, de fait, les appendices d'un livre prennent la forme d'annexes.
Fork (2008-08-06T11:51:02Z)
<tetratrichotomie = on> Tiens, je croyais que les tables des matières étaient toujours à la fin (et les sommaires au début)?! Mais je n'ai pas rapidement réussi à trouver une réponse. C'est donc une vrai question.
Et « appendice » n'est il pas une traduction maladroite directe d'``appendix''? En français on dirait plutôt annexe, non? <tetratrichotomie = off>
En tout cas, même si tu as dû passer par des voies compliquées, le document final est plutôt joli.
ivo (2008-08-05T14:48:04Z)
ha ok ! Je pense alors à Amaya, editeur navigateur qui dispose de fonctionnalités d'impression comme la "table des matières" mais je ne sais pas si ça couvre tes besoins (à mon avis non).
Ruxor (2008-08-05T13:38:01Z)
ivo → Je veux bien croire qu'imprimer le HTML donne un PDF qui reflète ce qui est dans le HTML, mais ce qui est dans le HTML n'est pas ce que je veux imprimer parce qu'il y a plein de choses qu'on ne peut pas exprimer en HTML+CSS. Par exemple, en HTML+CSS, je ne vois vraiment pas comment on pourrait faire apparaître les numéros de page dans la table des matières (ce qui est quand même la moindre des choses pour la table des matières d'un livre imprimé). En fait, HTML+CSS n'est absolument pas approprié à la réalisation de documents imprimés.
ivo (2008-08-05T12:55:16Z)
A partir d'un mac l'impression pdf de la page web donne un fichier pdf similaire à ce qu'on lit sur la page en html, je n'y ai vu aucune erreur ou "mauvaise qualité". Les liens continuent bien sûr de pointer sur des pages "en ligne" (les chapitres). Le reste, l'encodage, la mise en page, etc, sont les mêmes.
Ruxor (2008-08-05T11:32:44Z)
¬Alain → Il m'a semblé que CDuce était approprié pour le traitement de données hautement structurées mais que lorsqu'on cherche à traiter de façon impérative un schéma XML où essentiellement tout est du #PCDATA ça ne serait pas un bon choix. (Il faut dire aussi que les exemples que j'ai trouvés sur le site m'ont surtout paru abominablement compliqués.)
BR → Merci pour ce lien, c'est intéressant !
FX (2008-08-05T11:04:21Z)
Le B5, c'est sympa, j'ai fait imprimer ma thèse comme ça. Par contre, c'est super dur de trouver un service de reprographie qui sache faire ça (j'ai fini par le faire faire à la repro d'Orsay, mais ça a pris un temps fou à les convaincre).
BR (2008-08-05T07:07:54Z)
Le projet Tex-Gyre propose une version OpenType assez complète des polices classiques: Times, Palatino, Bookman, New Century Schoolbook etc…, renommées en Termes, Pagella, Bonum, Schola etc… http://www.gust.org.pl/projects/e-foundry/tex-gyre/ en vue, entre autre, de leur utilisation sous Tex. Tu devrait y trouver les versions cyrilliques et grecques de New Century Schoolbook.
Attention toutefois: je trouve les points sur les i ridiculements petits sur ces polices.
Je ne suis pas Alain (2008-08-05T05:40:08Z)
Ooooh, tu n'as pas essaye Cduce ?
phi (2008-08-04T22:51:51Z)
Ooooh, tu n'as pas essayé Microsoft Word?
Ruxor (2008-08-04T20:10:52Z)
Bubu → Oui, a posteriori c'est totalement clair que XeTeX était une bien meilleure solution (d'ailleurs, c'est ce que j'utilise pour mes « Fragments littéraires gratuits », <URL: http://www.madore.org/~david/lit/fragments.pdf >). J'espérais que OpenDocument me donnerait plus de souplesse dans le formatage (par exemple pour positionner une image c'est clairement OpenDocument qui a l'avantage), mais en fait c'était trompeur.
Par contre, pour produire du XML, je pense qu'un writer m'aurait ennuyé plus qu'autre chose parce que mon programme ne produit pas l'arbre de sortie dans l'ordre logique (notamment, il y a la balise « styles automatiques » et la balise « contenu de la table des matières » qu'il faut remplir au fur et à mesure qu'on rencontre des choses à y mettre).
Marc (2008-08-04T18:52:50Z)
Pour résumer, il y a quelques années, tu es passé de Sprint à emacs, et c'est à ce moment-là que les difficultés sont apparues ;-)
Bubu (2008-08-04T18:30:08Z)
Pourquoi diable ne génères-tu pas du LaTeX (compilé avec XeTeX pour faire joujou avec Unicode et les polices) à partir de ton XML ? Le format sera beaucoup plus simple, la transformation peut très probablement s'écrire naturellement en XSLT, la qualité typographique du résultat sera bien meilleure (ligatures, césure, etc.), pas de problèmes d'inclusion d'images vectorielles et tu n'auras pas besoin d'une usine à gaz comme OpenOffice. Bien sûr, il y a quelques artefacts de (La)TeX un peu pénibles, comme les caractères actifs, mais c'est le genre de choses pour lequel <xsl:text disable-output-escaping="yes" /> (en XSLT 1.0) ou, mieux, <xsl:character-map /> (en XSLT 2.0) marchent très bien. Pour un travail de ce genre, il n'y a guère de raison de ne pas utiliser XSLT 2.0, qui exige nettement moins de masochisme que son petit frère.
Par ailleurs, si tu ne veux vraiment pas d'XSLT, plutôt que d'utiliser DOM pour écrire du XML, utilise plutôt un writer (comme par exemple <URL: http://xmlsoft.org/html/libxml-xmlwriter.html >), ce sera nettement plus confortable.