Encore une avalanche de liens de la part d'Eric White sur la structure OPC du format Open XML :
- Réaliser des transformations XSLT sur un document Open XML (un sujet qui tombe à pic pour une personne qui m'a demandé cela il y a quelques jours), A LIRE ABSOLUMENT. Merci à Eric White pour cette série de grande qualité :
- Dans le sens de mon post sur la transformation d'un IEnumerable en feuille Excel, Eric (et oui toujours le même), la transformation en CSV :
Egalement un excellent post du grand gourou XML qu'est Rick Jellife autour des standards et de la crise financière du moment :
http://broadcast.oreilly.com/2008/09/the-derivatives-crisis-and-standards.htmlBonne lecture
Grand adepte du Point & Click depuis les Monkey Island en passant par la série complète des Indiana Jones, Broken Sword, Runaway et So Blond, voici qu'une équipe allemande d'amateurs a réalisé une suite au Chevalier de Baphomet 2, disponible gratuitement, nommé ... Les Chevaliers de Baphomet 2.5 ! Le demi parce qu'il ne s'agit pas réellement d'une suite officiel, bien que le studio de Revolution Software semble être à l'appui.
Vous pouvez le télécharger à cette adresse : http://www.brokensword25.com
Le jeu est plutôt simple pour les fans de Click & Point et il ne vous faudra pas plus de 4 à 5 heures pour terminer le jeu. Une fois fini, vous disposerez d'un code pour vous rendre à l'adresse : http://bonus.brokensword25.com/content/ et consulter les musiques, graphiques ainsi que les tests de développement :
Le jeu est bien fini et permet de retrouver beaucoup de personnage de la première aventure, un peu trop de monde peut-être même, et les énigmes s'enchaînent sans trop de difficulté. Un jeu a la portée de tout le monde et les fans de Broken Sword ne passeront sans doute pas à côté de scènes joliment créées ou refaites pour l'occasion (dont le café ...).
Enjoy it !
Update 08/10 : nouveaux posts et blogs
A suivre sur le blog de Alex Brown, membre du SC 34 et participant à la réunion qui a lieu en ce moment même :
Doug Mahugh (MS Corp) se prend aussi au jeu :
Remarque : Je mettrais ce post à jour, avec les prochains posts sur le sujet.
Voici les quelques liens techniques intéressants autour de Open XML de cette dernière semaine :
PowerTools pour Open XML ne possède pas d’installeur pour le moment, et il est parfois bien difficile de demander à un IT d’installer Visual Studio 2008 sur son serveur pour déployer la DLL nécessaire à l’utilisation des cmdlets Open XML (et à juste titre. Malgré tout il peut le déployer manuellement en quelques secondes). Après quelques temps passé sur un script Wix, voici une ébauche (cf la pièce jointe à ce post pour avoir toutes les ressources, les scripts etc) d’un installeur que je vous propose sous licence BSD (pour résumer, vous pouvez en faire ce que vous voulez !).
Le résultat avec un beau vert qui ne va pas sans rappeler les couleurs de Codeplex (couleurs dont je ne suis pas fan soit dis en passant, hein Sara) :
Attention : la licence présentée dans la capture ci-dessus est celle sous laquelle je vous fournie le script Wix, pas celle de PowerTools pour Open XML qui est de type Ms PL.
Les scripts et les ressources à mettre dans un répertoire nommé ‘Setup’ à la racine du projet PowerTools :
N’oubliez pas de télécharger les plugins et outils pour construire le MSI : http://wix.sourceforge.net/
Retrouver le projet Power Tools for Open XML à cette adresse : http://www.codeplex.com/PowerTools/license
Egalement n’hésitez pas à répondre au sondage de Eric White (évangéliste Open XML MS Corp et responsable du projet) et à me faire parvenir vos feedbacks, améliorations, etc par mail ou commentaires sur ce post. En cas de problème d’installation ou de déploiement n'’hésitez pas non plus à me contacter !
PowerTools for Open XML doesn’t have an installer yet, and it’s always difficult to ask to an IT guy to install Visual Studio 2008 on a server just to deploy a PowerShell assembly ! So after several hours trying to make things look good, here’s my version of the PowerTools for Open XML installer (released under BSD : you can do what you want with it). You’ll find all the ressources and scripts in attachment.
The result recalls the ‘beautiful green’ of Codeplex (I’m not a fan of this color but Codeplex is still a great place :p).
Be careful, the above license is not the one uses by PowerTools for Open XML (which is a Ms PL license).
All the scripts and resources have to be put in a folder named ‘Setup’ at the root of the PowerTools for Open XML project :
Don’t forget to download Wix plugins and tools to build the MSI installer: http://wix.sourceforge.net/
Here’s the PowerTools for Open XML Codeplex project page where you can download binaries and sources as well as screencasts: http://www.codeplex.com/PowerTools/license
Don’t hesitate to send me feedbacks, potential enhancements or comments.
Enjoy !
Quelques liens en cette fin de semaine (étant en congé demain, les voici en avance) :
Transformer vos documents Word en XAML
Une nouvelle release pour ce projet de conversion de documents Word en XAML (WPF et Silverlight 2) sous licence MS-Public License. On attend avec impatience une hypothétique version pour PowerPoint … Pour en avoir
Pour le lien : http://www.codeplex.com/Word2007ToXaml
If you want to dump an IEnumerable<T> instance into an Excel spreadsheet document (using the latest Open XML SDK v2 CTP), here’s the code (also available in the zip in attachment) :
static class OpenXMLExtensions
{
public static void ToSpreadsheetML<T>(this IEnumerable<T> items, String path) where T : class
{
ToSpreadsheetML<T>(items, new FileStream(path, FileMode.OpenOrCreate));
}
public static void ToSpreadsheetML<T>(this IEnumerable<T> items, Stream stream) where T : class
{
List<String> headers = (from PropertyInfo p in typeof(T).GetProperties() select p.Name).ToList<String>();
List<List<String>> values = new List<List<String>>(items.Count());
foreach (T item in items)
{
List<String> valCols = new List<string>();
object obj = null;
foreach (PropertyInfo property in typeof(T).GetProperties())
{
obj = property.GetValue(item, null);
if (obj == null)
valCols.Add("");
else
valCols.Add(obj.ToString());
}
values.Add(valCols);
}
using (SpreadsheetDocument package =
SpreadsheetDocument.Create(stream, SpreadsheetDocumentType.Workbook))
{
package.PackageProperties.Creator = "Julien Chable - Wygwam (www.wygwam.com)";
var workbookPart = package.AddWorkbookPart();
GenerateWorkbookPart().Save(workbookPart);
var worksheetPart = workbookPart.AddNewPart<WorksheetPart>("rId1");
GenerateWorksheetPart(headers, values).Save(worksheetPart);
}
}
#region Private methods
private static Workbook GenerateWorkbookPart()
{
var element =
new Workbook(
new BookViews(
new WorkbookView() { XWindow = 120, YWindow = 150, WindowWidth = (UInt32Value)19095U, WindowHeight = (UInt32Value)8415U }),
new Sheets(
new Sheet() { Name = "IEnumerableDemo", SheetId = (UInt32Value)1U, Id = "rId1" }));
return element;
}
private static Worksheet GenerateWorksheetPart(List<String> headers, List<List<String>> values)
{
var element =
new Worksheet(
new SheetViews(
new SheetView() { TabSelected = true, WorkbookViewId = (UInt32Value)0U }),
new SheetFormatProperties() { DefaultRowHeight = 15D },
PopulateData(headers, values));
return element;
}
private static SheetData PopulateData(List<String> headers, List<List<String>> values)
{
Row headerRow = new Row();
SheetData data = new SheetData(headerRow);
foreach (String h in headers)
headerRow.Append(new Cell(new CellValue(h)) { DataType = CellValues.String });
foreach (List<String> vals in values)
{
Row valsRow = new Row();
foreach (String val in vals)
valsRow.Append(new Cell(new CellValue(val)) { DataType = CellValues.String });
data.AppendChild(valsRow);
}
return data;
}
#endregion
}
The previous code add each object property with its value convert into a string (with ToString()) and then use the new Open XML SDK v2 to generate a document from scratch.
Here’s the example with a List<Person>:
List<Person> people = new List<Person>();
people.Add(new Person() { Name = "Julien",
Blog = "http://blogs.developpeur.org/neodante/" });
people.Add(new Person() { Name = "Aurélien",
Blog = "http://blogs.developpeur.org/aurelien/" });
people.ToSpreadsheetML("demo.xlsx");
Enjoy (thanks to Aurélien to have Linquify the code a bit)
Disponible au grand public depuis quelques semaines maintenant, le protocole Protocol Buffers apporté par Google se voit tout doucement doter d’une version pour .NET grâce à de multiples projets communautaires. En effet, pour être un protocole multiplateforme – parmi celle les plus populaires - il manquait encore la prise en charge de .NET aux plateformes proposées par Google (Java, C++ et Python sont supportés).
Un grand merci donc aux projets suivants (il en existe également d’autres beaucoup moins avancés) :
- http://github.com/jskeet/dotnet-protobufs/tree/master par John Skeet (maintenant chez Google, merci Flavien). On pourrait donc presque parler d’une extension officielle à ce que Google a sortie.
- http://code.google.com/p/protobuf-net/ Un projet qui va bon train et qui privilégie une approche par attribut et non par génération de classes issues d’un fichier proto. L’avantage en revanche est que vous pouvez utiliser WCF et autres .NETterie. De nombreux exemples (Silverlight, Mono, etc) sont également disponibles.
Attention Protocol Buffers n’est pas fait pour exposer vos services à vos clients ou vos utilisateurs (même si ça pourrait le devenir), ce n’est pas un remplaçant du web service, mais un protocole d’échange optimisé pour la communication entre les serveurs d’une infrastruture logicielle.
Il y a des outils comme celui-ci qui ne doivent pas passer inaperçu ! Tout le monde connaît .NET Reflector qui permet par réflexion (et une touche de savoir faire) d’avoir les sources et autres informations d’une assembly .NET. Faire de la réflexion sur une DLL paraît plutôt logique dans l’approche, mais quid de la réflexion d’un document bureautique ? En effet, il paraitrait logique pour une application portant ce nom d’ouvrir simplement le Zip et de présenter le XML des parties comme il en existe déjà une multitude.
Evidemment, dit comme cela, vous devez vous doutez que DocumentReflector n'est pas un simple explorateur Zip/XML ! En effet, n’oublions pas que cet utilitaire est disponible avec le SDK Open XML qui apporte principalement de nouvelles APIs … et cet utilitaire porte très bien son nom : il permet tout simplement d’avoir le code de génération des documents Open XML ! C’est à dire qu’à partir d’un document existant, DocumentReflector se chargera pour vous de générer soit l’intégralité du code pour générer le document, soit juste la partie qui vous intéresse (exemple, le contenu d’une feuille Excel seulement ou la partie de styles).
L’outil se présente sous la forme d’une fenêtre possédant trois vues :
- Gauche : la structure du fichier Open XML avec ses parties et la structure typée du XML,
- En haut à droite : le code XML associé à la partie,
- En bas à droite : le code C# qu’il vous faudra pour générer à partir de rien la même structure XML et d’objets Open XML (parties, etc).
Autant dire que les équipes de Microsoft ont réalisées un excellent outil qui aidera aussi bien les débutants à démarrer, que les experts à augmenter leur productivité à créer ou à manipuler des documents Open XML.
A votre avis, combien de temps il m’a fallu pour créer le code final de ce post ? La réponse : 3 minutes en comptant les arrangements de code et la création du document dans Word.
Je rajoute cet outil dans mon top 3 des outils au côté de XML Spy et de Package Explorer, et vous ?
Avec les APIs de cette version du SDK Open XML V2, viennent plusieurs outils dont l’utilité n’est pas a écarter ; au mieux ces programmes utilitaires deviendront les outils que vous utiliserez le plus lors de vos projets.
Le Class Loader
Cet utilitaire représente la documentation par excellence de ce nouveau SDK : documentation des classes à la MSDN et référence aux spécifications du format. Le tout peut-être consulter via un index ou via le modèle objet en prenant en compte les relations entre les classes. Ainsi vous n’avez pas une liste de classe sans relation les unes à côté des autres, mais bien une hiérarchie par niveau qui suit le contexte d’utilisation des classes. Par exemple vous trouverez la classe Paragraph en dessous de la classe Body qui elle-même se trouve en dessous de Document ; car de façon logique vous atteindrez les paragraphes d’un document Word en faisant Document.Body.Elements<Paragraphs>. Ce système vous permettra de trouver très rapidement les classes disponibles et les possibilités de ce SDK.
Une très belle façon de documenter ce genre d’APIs :
OpenXmlDiff
Cet outil permet de faire une comparaison entre deux documents Open XML. Je vous avais déjà présenter l’outil de Altova – DiffDog - qui permettait de faire de même. Microsoft nous gratifie donc d’un utilitaire gratuit quant à lui, afin de pouvoir faire de même. Pratique lorsque vous générez des documents et ne comprenez pas pourquoi Office arrive à créer un formatage particulier, cet utilitaire vous montrera ce que vous n’avez en général pas fait de votre côté …
A suivre
Il reste encore un outil à traiter, le Document Reflector, dans ce lot d’utilitaires de cette nouvelle monture du SDK Open XML. Néanmoins je lui réserve un post rien qu'à lui car c’est le genre d’outil qui fera que désormais plus aucun document Open XML ne vous résistera ou presque. A suivre prochainement !
La sortie de la V2 du SDK devrait donner un nouveau souffle aux projets utilisant le format Open XML : des gains de productivité, moins de lignes de code et de tests et de nouveaux outils pour améliorer la qualité de vos applications. Même si Linq To XML rendait les choses beaucoup plus simples pour manipuler ou générer les structures XML, il n’en reste pas que cela est compliqué et chronophage. De plus, sans le SDK, vous devez connaître les espaces de nom, les éléments, la structure des documents, etc que vous trouverez évidemment bien documenté dans la spécification. Heureusement le SDK V2 rend tout cela beaucoup plus simple comme vous allez le constater.
Premier projet
Comme pour tout projet avec le SDK Open XML, il va vous falloir tout d’abord ajouter la référence vers la nouvelle DLL qui, puisque c’est une version 2, porte le même nom que son prédécesseur : DocumentFormat.OpenXml.dll. Une fois la référence ajouter à votre projet, vous voilà fin prêt pour démarrer !
Néanmoins, une chose à changer par rapport à la précédente version du SDK : le nombre d’espace de noms disponible !
Pour rappel, la précédente version ne proposait que le seul espace de nom Packaging. Il y a donc eu pas mal de travail de la part de l’équipe de développement (que je salus au passage, ils se reconnaitront) et les feedbacks que nous leur avions communiquer ont visiblement portés leurs fruits.
Maintenant qu’avons nous à notre disposition : des espaces de noms structurant, des classes typées avec des méthodes adéquates, des énumérations, … mais qu’elle différence concrètement avec l’approche Linq to XML ?
Avant :
using (WordprocessingDocument wordDoc =
WordprocessingDocument.Open("Sample.docx", true))
{
MainDocumentPart mainPart = wordDoc.MainDocumentPart;
XDocument doc = XDocument.Load(XmlReader.Create(mainPart.GetStream()));
XNamespace w = "http://schemas.openxmlformats.org/wordprocessingml/2006/main";
var pars = doc.Element(w + "document")
.Element(w + "body")
.Elements(w + "p");
foreach (XElement par in pars)
{
StringBuilder sb = new StringBuilder();
foreach (XElement r in par.Elements(w + "r").Descendants(w + "t"))
{
sb.Append(r.Value);
}
Console.WriteLine(sb.ToString());
}
}
Après :
using (WordprocessingDocument wordDoc =
WordprocessingDocument.Open("Sample.docx", true))
{
MainDocumentPart mainPart = wordDoc.MainDocumentPart;
// Approche API SDK Open XML
foreach (Paragraph par in mainPart.Document.Body.Elements<Paragraph>())
{
StringBuilder sb = new StringBuilder();
foreach (var run in par.Elements<Run>())
foreach (var text in run.Elements<Text>())
sb.Append(text.Text);
Console.WriteLine(sb.ToString());
}
}
Vous remarquerez qu’il n’y a plus de schéma XML et plus de nom d’élément à connaître. Les noms des éléments possèdent un équivalent en classe typée et sont atteignables en tant que tel par l’application. Fini les objets XElement non typé, vous avez maintenant à votre disposition des objets comme Paragraph, Run et Text. Vous pouvez bien évidemment requêter les éléments de façon plus orienté Linq (ici simplifié pour la démonstration), en notant que le SDK Open XML prend en charge le lazy loading et les annotations.
Génération de documents Word
La génération d’un document Open XML de type Word était déjà rendu simple par l’utilisation du SDK v1 et de Linq to SQL, mais voyez ce que vous pourrez faire avec la V2 :
using (WordprocessingDocument wordDoc =
WordprocessingDocument.Create("SampleDemo.docx",
DocumentFormat.OpenXml.WordprocessingDocumentType.Document))
{
// Création d'une nouvelle partie de contenu
MainDocumentPart mainPart = wordDoc.AddMainDocumentPart();
// Création d'un nouveau paragraphe
Document mainDoc = new Document(
new Body(
new Paragraph(
new ParagraphProperties(
new ParagraphStyleId() { Val = "Title" }),
new Run(
new RunProperties(
new Italic()),
new Text("Bienvenue au SDK Open XML V2 !")
))));
// Enregistrement de la partie
mainDoc.Save(mainPart);
// Création d'une nouvelle partie de style
StyleDefinitionsPart stylePart = mainPart.AddNewPart<StyleDefinitionsPart>();
Styles styles = new Styles(
new Style(
new Name() { Val = "Title" },
new BasedOn() { Val = "Normal" },
new NextParagraphStyle() { Val = "Normal" },
new LinkedStyle() { Val = "TitleChar" },
new UIPriority() { Val = 10 },
new PrimaryStyle(),
new Rsid() { Val = "002C2DBE" },
new ParagraphProperties(
new ParagraphBorders(
new BottomBorder() { Val = BorderValues.Single, Color = "auto", Size = (UInt64)4UL, Space = (UInt64)1UL }),
new SpacingBetweenLines() { Line = 240, LineRule = LineSpacingRuleValues.Auto },
new ContextualSpacing()),
new RunProperties(
new RunFonts() { AsciiTheme = ThemeFontValues.MajorHighAnsi, HighAnsiTheme = ThemeFontValues.MajorHighAnsi, EastAsiaTheme = ThemeFontValues.MajorEastAsia, ComplexScriptTheme = ThemeFontValues.MajorBidi },
new Spacing() { Val = 5 },
new FontSize() { Val = (UInt64)52UL },
new FontSizeComplexScript() { Val = (UInt64)52UL })
) { Type = StyleValues.Paragraph, StyleId = "Title" });
// Enregistrement des styles
styles.Save(stylePart);
}
Ce code donne le résultat suivant (sans avoir Office d’installer sur sa machine ou son serveur) :
Voici par exemple ce que génère pour vous le modèle objet d’un paragraphe :
<w:p xmlns:w=\"http://schemas.openxmlformats.org/wordprocessingml/2006/main\"><w:pPr><w:pStyle w:val=\"Title\" /></w:pPr><w:r><w:rPr><w:i /></w:rPr><w:t>Bienvenue au SDK Open XML V2 !</w:t></w:r></w:p>
Le XML généré est propre et vous n’avez même pas toucher au XML pour générer ce document qui s’ouvre parfaitement avec Office et conforme au spécification Open XML sans aucun problème. Quel plaisir – pas que le XML soit atroce – de ne plus avoir à générer soit même la structure en se référant à la spécification. Vous trouverez les sources de ces projets en pièce jointe de ce message.
Les prochains posts détailleront les autres formats et les outils mis à votre disposition pour pouvoir créer des documents en quelques minutes (vous comprendrez bien le sens de cette phrase).
Le tant attendu SDK Open XML V2 est enfin téléchargeable ! Disponible sous la forme d’une Community Technology Preview, cette version du SDK apporte enfin un modèle objet pour manipuler les documents, des outils de comparaison de fichiers Open XML, un explorateur de classes et ce n’est pas tout : un outil d’aide au code pour créer des documents.
Alors que la version 1 ne proposait qu’un typage fort des parties du document – qui vous laissait vous débrouiller tout seul avec le XML du contenu - cette version permet aujourd’hui de générer ou de manipuler le contenu des parties avec un modèle objet adéquat. En gros, cette version du SDK génère pour vous le XML des parties afin d’en constituer le contenu de votre document, avec un gain de productivité étonnant. Pour ceux qui veulent démarrer avec Open XML, plus besoin de lire la spécification de long en large, une introduction au format suffira.
Vous l’aurez compris, la V2 du SDK Open XML est une grosse release (pas seulement par sa taille de 70Mo) qui apporte bien plus qu’une nouvelle API ; et vous vous en doutez bien, quelques posts arriveront très prochainement pour parler plus en détail de chaque nouveauté de ce SDK V2. Cette version du SDK n’est qu’au stade de la CTP, et c’est pourquoi vous pouvez retourner vos feedbacks (suggestions, bugs, etc) avec les équipes de développement grâce au site Connect afin d’en améliorer la qualité.
Pour le téléchargement, c’est par ici !
Update : N'oubliez pas le SDK V2 est en Community Technology Preview et que par conséquent le déploiement dans un produit ou chez un client est interdit jusqu'à la Go Live. De même, le statut de ce SDK ne garantie pas que des changements importants et des corrections pourront être effectuer dans les futures versions.
Avoir son brevet de pilote de planeur et de pilote d’Avion est une chose - encore faut-il les renouveler et faute de temps, je n’ai pas eu le temps de remettre mes fesses dans un cockpit depuis 2006 en grande partie grâce à Nicolas – et voler quotidiennement en est une autre. Pour ceux qui possèdent Flight Simulator X pour s’envoyer virtuellement en l’air de temps en temps (hein Christian !), je vous avais parler d’un SDK pour créer des extensions à FSX. Néanmoins si vous désirez allez encore plus loin et créer votre propre application de simulation avec le moteur de FSX, je viens de découvrir Microsoft ESP que je vous laisse le soin d'essayer (démos, etc de disponible et l'ensemble est à la disposition des abonnés MSDN).
Au vu du prix du pétrole pour les voitures – les avions tournent avec de l’essence encore plus raffiné, par exemple avec de la 100LL, je vous laisse en déduire tout seul la tendance du prix au litre – les moteurs de simulations aéronautique ont un bel avenir pour l’apprentissage des pilotes et les tests et démonstrations physiques. En tout cas Microsoft propose le moteur et y a pas à dire, ça en jette même si les petites configurations devront s’en abstenir.
L’API pour Open XML est sortie il y a quelques semaines déjà, néanmoins voici quelques détails et liens pouvant vous apporter quelques lumières sur ce fameux SDK dont certaines personnes (n’est-ce pas Alexandre ?) semblent éprouver quelques difficultés à se servir ou à comprendre sa portée réelle.
Pour rappel, l’assembly WindowsBase.dll apporté par .NET 3.0 fournissait l’espace de nom System.IO.Packaging. Si vous avez .NET 3.0 (Vista ou Windows Server 2008) ou 3.5 d’installé, vous devriez pouvoir l’utiliser sans aucun problème dans vos applications. Le SDK Open XML sorti bien plus tard (lien de téléchargement ici), est une assembly DocumentFormat.OpenXml autonome qui fournit l’espace de nom DocumentFormat.OpenXml.Packaging. Le fait que cette assembly soit autonome vous permet et de la redistribuer avec vos applications (utilisant au moins le framework .NET 3.0) sans avoir à mettre à jour le framework de la machine vers le 3.5 qui est horriblement long à installer (et je ne parle pas du SP1 …).
Migrer de la CTP vers la RTM
Pour ceux qui aurait encore la version CTP d’installer sur leur machine de développement et qui souhaiteraient passer à la version finale, la première chose à faire pour migrer vos projet est de référencer la nouvelle Assembly DocumentFormat.OpenXML.dll. Remplacez tous vos using Microsoft.Office.DocumentFormat.OpenXml.Packaging; par using DocumentFormat.OpenXml.Packaging;. Et oui Microsoft à retiré son nom et ‘Office’ devant l’espace de nom final !
Un SDK, oui mais pour quoi faire en fait ? Ca change quelque chose ?
Notez que les deux espaces de noms n’offrent de fonctionnalités que pour manipuler l’enveloppe Open Packaging Convention - la structure interne du document – et non le XML des parties : vous devez toujours utiliser les API XML pour vous débrouiller avec la structure XML des parties (et lire les spécifications). Pour résumer, vous n’avez pas – encore, en attendant la V2 du SDK – de méthodes vous permettant de réaliser des tâches du genre : ajouter un paragraphe, insérer une image, spécifier la valeur d’une cellule, etc.
Pour les personnes désirant un peu de documentation sur le SDK Open XML, c’est par ici : http://msdn.microsoft.com/en-us/library/bb448854.aspx. Pour ceux qui veulent des articles d’introduction, voici deux bons articles sur le sujet (créé avec la CTP : Partie 1 et Partie 2 – pensez à changer les espaces de noms utilisés) de Franck Rice, et en Français en plus ! Notez également dans vos flux, les blogs de Eric White (évangéliste Open XML MS Corp) et de Doug Mahugh (ancien évangéliste Open XML et maintenant des standards dans Office).
Voilà pour la petite piqure de rappel !
Vous générez des documents Open XML, Office ne veut pas les ouvrir ? Voici quelques moyens d’en découdre avec un Office qui n’est pas bavard sur les erreurs …
Voici les causes d’erreur les plus probables et leur solution :
- Content Type : source principale des erreurs de ‘corruption’ de documents Open XML => A vérifier en premier, on oublie toujours le content type d’une partie que l’on rajoute (l’API de System.IO.Packaging le fait pour vous). Dézipper tout votre document et vérifier que chaque partie possède bien une entrée de Content Type en adéquation avec votre contenu,
- Relations : les relations associent les parties entres elles et permet d’avoir une cohésion des données dans un document. Si une des parties n’est pas référencé, Office ne saura pas la retrouver (quelques cas exceptionnel pour les parties principales avec la bonne convention de nommage mais Office râlera quand même à l’ouverture. Attention aux relations implicites également (il en existe quelques unes, par exemple avec les parties de Custom XML),
- XML des parties mal formé ou invalide : vérifiez évidemment que vos structures XML soient bien formées (la grammaire XML est respectée : 1 balise ouvrante pour une balise fermante, respect des prototypes - & > etc –, etc) et valide au schéma de la partie (respect du schéma XSD référencé en début de structure XML avec les espaces de noms)
Le
SDK Open XML possède une méthode de validation de document (uniquement pour les parties et les relations, pas encore pour le contenu XML) et
PackageExplorer possède un vérificateur (qui cette fois-ci valide également le XML de vos parties).
Utilisation de lastRenderedPageBreak
Pour ceux qui ne connaissent pas cet élément permettant d’informer votre logiciel de traitement de texte de la césure du rendu d’une page, le voici pour vous :
2.3.3.13 lastRenderedPageBreak (Position of Last Calculated Page Break)
This element specifies that this position delimited the end of a page when this document was last saved by an
application which paginates its content.
[Guidance: This element shall be used by applications to specify the locations of page breaks within a document
when it is saved as WordprocessingML, in order to allow other applications (e.g. assistive software) to utilize this
information when reading the document. end guidance]
[Example: Consider a run which consists of the text This is the end of the page, where the word end
was the last word on a page. If the application saving this file had paginated this content, that information may
be saved with the file as follows:
<w:r>
<w:t>This is the end</w:t>
<w:lastRenderedPageBreak/>
<w:t xml:space="preserve"> of the page</w:t>
</w:r>
The lastRenderedPageBreak element indicates that there was a page break resulting from pagination of this
content, which occurred between the word end and the word of. end example]
Utilisez cet élément à bon escient (mais utilisez-le car les routines automatiques exploitant les documents Open XML en sont friands pour découper un document au bon endroit … exemple transformation en HTML/PDF ou XPS) mais sachez les mettre au bon endroit. Pourquoi cet élément est aussi important car il permet dans une moindre mesure de pouvoir préparer vos documents à des logiciels d’accessibilité aux personnes handicapées. Si vous ne savez pas calculer leur emplacement, omettez-les tout simplement. Cela peut conduire selon l’implémentation de Open XML à des déformations de texte, voir à un saut de page non voulu (attention cet élément n’est pas le saut de page “PageBreak” ! C’est un élément non visuel, d’information uniquement). On ne sait pas ce qu’une implémentation désirant être absolument conforme à une autre, est capable de faire avec ce genre d’éléments.
Téléchargez le projet sur le site officiel et installez le :
Ouvrez le ruban pptPlex :
Choisissez un magnifique fond et insérez des sections dans votre présentation :
Et utilisez le en lançant la présentation depuis le ruban pptPlex :
Addin vraiment bien réalisé mais attention aux présentations lourdes (beaucoup de slides, plein d’image, de formes et d’animations) … les lenteurs arrivent vite, très vite !
Impact dans le document Open XML
On pourrait se demander comment Microsoft a réussi à stocker des données supplémentaire dans le document Open XML. Et si vous vous le demandez, voici quelques unes des modification dans le document nécessaires pour intégrer pptPlex :
Ajout type de contenu de tag :
<Override PartName="/ppt/tags/tagN.xml" ContentType="application/vnd.openxmlformats-officedocument.presentationml.tags+xml"/>
Ajout de partie de tag dans /ppt/tags avec un contenu similaire :
<p:tag name="PLEXMETADATA" val="<?xml version="1.0" encoding="utf-16"?>
<Metadata xmlns:xsi=&q …
Et quelques autres éléments du document qui s’adaptent. Comme quoi on peut toujours innover dans une application et même si la prouesse de stockage relève plus du bidouillage (embarquement de la structure XML encodé dans un attribut ! Mais difficile au moment d'un test de faire autrement il faut le reconnaître), le résultat est plutôt sympathique pour naviguer dans une présentation PowerPoint.
Conclusion
Un addin intéressant qui ne semble pas indispensable pour le moment (quelques fonctionnalités/usages à prendre dans iWorks avant celle-ci) car il y a toujours d’autres fonctionnalités qui manque et notamment celle des transitions 3D (je sais je me répète depuis 2005 sur ce sujet - OOo 2.4 le fait déjà sur Linux) !!! En standard avec Office 14 ?
Ce post n’a pas voulu partir ni jeudi ni vendredi, le voici donc !
Des mise à jours à n’en plus finir !
Hésitant à ne faire qu'un relai d’information sortant tout droit du autre post, ici de Doug Mahugh (j’avoue avoir loupé moi-même les annonces de ces produits), voici quand même l'ifnormation du lot de mises à jour autour des outils Open XML et de ODF :
Open XML/ODF Translator Version 2.0. Version 2 of the ODF translator project has been released. It includes significant performance improvements for spreadsheets, as well as numerous new features for all three document types and various bug fixes and enhancements based on feedback from users of Version 1. See the ODF translator team blog for all the details.
Docx4j version 2.0. Speaking of versions 2.0, a new release of docx4j is now available. This is a Java developer tool that creates an in-memory representation of a WordprocessingML document. See the use cases for examples of typical uses of docx4j.
OpenXMLDiff vNxt. Pranav Wagh said a while back that he'd start contributing to the OpenXMLDiff project, and he has already made a big difference. See his blog post last month for details (including a nice GUI interface to the core DLL), and there's an even newer build available now on the OpenXMLDiff project page.
ODF 1.0 errata released for public comment. The OASIS ODF TC has released an ODF 1.0 errata for public feedback. Jesper-on-the-spot posted it before I even saw the announcement on the OASIS list, and has a few interesting observations and comments. If you want to provide feedback, you'll need to do so by August 22.
Open XML Power Tools / Workflow Foundation
L’équipe Staff Dotnet continue ses posts sur PowerTools avec un post concernant l’utilisation dans un workflow WF.
Voici ceux de Eric White sur le même sujet :
Utilisation de Linq To XML avec Open XML
Voici les liens MSDN ou d’Eric White (évangéliste MS Corp pour XML/Open XML) qui devrait compléter les votre sur l’utilisation de Linq To XML avec Open XML:
C’est officiel, les appels de l’Afrique du Sud (Christian on va toujours là bas pour la coupe du monde ?), du Brésil, de l’Inde et du Vénézuela contre DIS 29500 aka Open XML ont été rejetés par l’ISO.
Voici les résultats de l’ISO reçu par les membres de l’AFNOR dans leur messagerie :
| MB members | Yes | No |
| ABNT (Brazil) | X | |
| AENOR (Spain) | | X |
| AFNOR (France) | | X with comments |
| ANSI (USA) | | X |
| BSI (United Kingdom) | X with comments | |
| DIN (Germany) | | X |
| JISC (Japan) | | X |
| NEN (Netherlands) | X with comments | |
| SABS (South Africa) | X | |
| SAC (China) | X | |
| SCC (Canada) | X | |
| SN (Norway) | | X with comments |
| Total | 6 (50%) | 6 (50 %) |
La majorité des 2/3 (66,66%) n’a pas été atteinte, ce qui constitue un rejet de la prise en compte des appels contre la procédure de normalisation de Open XML qui bloquait son évolution à l'ISO afin d'être une norme publiée (est-ce encore une ruse des partisans de l'ODF ?).
Plus qu’aux journaux web de véhiculer la nouvelle, et le statut de IS29500 va pouvoir avancer à l’ISO, enfin !
Mise à jour 18/08/08 : Voici le lien officiel de l’ISO de cette annonce : http://www.iso.org/iso/pressrelease.htm?refid=Ref1151
Un rappport de l’Université de l’Illinois concernant l’interopérabilité entre les implémentations de Open XML et de OpenDocument a été rendu public fin de semaine dernière. Ce rapport de Jay Kesan et Rajiv Shah présente un tour d’horizon des produits (propriétaire ou Libre) du marché. L’introduction de ce rapport introduit bien le problème :
The belief is that by shifting to open standards, governments will benefit from choice, competition, and the ability to seamlessly substitute different vendor implementations. … While it is widely acknowledged that there are problems with interoperability across different formats, e.g., going from ODF to OOXML, there is an assumption here that all implementations produce the same ODF or OOXML.
Voici les résultats pour les implémentations Open XML :
| Implementation | Score brut | Pourcentage score brut | Pourcentage pondéré |
| Office 2007 | 148 | 100% | 100% |
| Office 2003 | 148 | 100% | 100% |
| Office 2008 (Mac) | 147 | 99% | 99% |
| OpenOffice | 141 | 95% | 96% |
| Pages | 142 | 96% | 95% |
| WordPerfect | 114 | 77% | 84% |
| ThinkFree Office | 101 | 68% | 83% |
| TextEdit | 52 | 35% | 43% |
Voici le résultat pour les implémentations ODF :
| Implementation | Raw score | Raw score Percentage | Weighted Percent |
| OpenOffice | 151 | 100% | 100% |
| StarOffice | 149 | 99% | 97% |
| Sun plug-in for Word | 142 | 94% | 96% |
| Plugin CleverAge pour WOrd | 139 | 92% | 94% |
| WordPerfect | 122 | 81% | 86% |
| KOffice | 121 | 80% | 79% |
| Google Docs | 117 | 77% | 76% |
| TextEdit | 55 | 36% | 47% |
| AbiWord | 48 | 32% | 55% |
Comme vous pouvez le constater, les implémentations sont loin d'être égale entre elles.
Quelques conclusions des auteurs :
There are several significant implications that flow from these tests. They include the lack of 100% compatibility between implementations, the lack of good implementations outside of Windows, and the overall performance of OOXML implementations.
The final implication stems from the surprisingly good results for OOXML implementations. Critics of OOXML have argued that it was too complex and difficult to implement. While OOXML is a long and complex standard, it is possible to offer good compatibility. In fact, our results suggest that implementations of OOXML work as well as implementations of ODF.
Il y a beaucoup d’autres commentaires (comme la vitesse d’exécution des implémentations, le nombre de celles-ci sur les plateformes, etc) et les auteurs font part de certaines limitations dans leurs tests (par exemple, limité aux documents de traitement de texte). Néanmoins il est clair que nous pouvons conclure :
- Le standard Open XML plus long que son concurrent ne rend pas beaucoup plus difficile son implémentation, ni ne limite l’interopérabilité des implémentations,
- Il y a encore du travail pour obtenir une excellent interopérabilité entre les implémentations (nécessite d’un jeu de tests commun ?),
Et pour finir, je dirais que ce n’est pas parce que vous choisirez un format ouvert que vous aurez une bonne interopérabilité et que vous ne serez plus dépendant d’une implémentation/d’un produit. Au vu des liens sur le côté droit de la page web du rapport, je dirais que ce rapport n’a pas été fait dans l’intention de promouvoir Open XML, ce qui n’est que plus flatteur.
Lien de téléchargement du rapport.
PS : A quand un test avec le SP2 – pre alpha - de Office 2007 ?
Les 10 derniers blogs postés
-
Monitoring et Patron de méthode par
Le blog de Marc Ranchin le il y a 2 heures et 20 minutes
-
ADO.NET Data Services Hooking POC v2 par
Matthieu MEZIL le il y a 2 heures et 34 minutes
-
Back from NYC ! par
.net is good... C# is better ;) le il y a 3 heures et 12 minutes
-
Hello World! par
Le blog de hamid le il y a 11 heures et 20 minutes
-
MSBuild Extension Pack sur codeplex par
Michel Perfetti [Miiitch] le il y a 12 heures et 39 minutes
-
TCB : Travailler en équipe sans réseau par
The Mit's Blog le il y a 15 heures et 50 minutes
-
Accès anonyme et les pages Forms / viewlsts.aspx... par
Nicolas Humann le il y a 19 heures et 43 minutes
-
l'Atelier 4 du coach C# est disponible par
Bernard Fedotoff le il y a 21 heures et 18 minutes
-
[WPF] Formatter l’affichage lors d’un binding, via StringFormat par
Thomas Lebrun le 10-07-2008, 10:22
-
WSC08 : Le bilan, Les Photos, Les Webcasts à voir ou à revoir par
Blog de Daniel TIZON [daniel] le 10-07-2008, 01:14
