<Glazblog/>

François Fillon, vos communiquants et vous-même nous insultez. Quand vous annoncez, fiers, 4000 personnes à Clermont-Ferrand alors que votre réunion a mobilisé deux des quatre salons de la Grande Halle, soit très précisément 1200 m2, vous vous FOUTEZ DE NOTRE GUEULE. Il y avait plusieurs rangées assises, une estrade, un espace vide entre l'estrade et les assis. Sur 1200 m2 il y avait donc au plus 1050 m2 utiles. Il y aurait donc eu 3.8 personnes PAR METRE CARRÉ...

C'est totalement impossible. Et les assurances du lieu n'ont pas pu vous autoriser pour une telle présence. Impossible.

Bref, il y avait 800 personnes, un nombre bien plus en conformité avec les photos. Et sur ces 800 personnes, les trois rangées assises montraient de nombreux parisiens descendus à Clermont pour vous soutenir. Bref, il y a eu AU PLUS 650 personnes à votre meeting à Clermont, dont un nombre certain d'organisateurs (visibles sur les photos).

Vous mentez, continuer à mentir, rementez, tout le temps. Votre équipe ment, continue à mentir, rement, tout le temps. Et pas d'un peu. Des énormités. Merde à la fin. Merde. Arrêtez de nous prendre pour des cons.

Done. I have added XUL-based support for OS X Touchbar to Postbox and that will certainly ship soon. It's then probably the first Gecko-based application with OS X Touchbar support... All in all, it was quite easy. I only regretted some very strange or sometimes inconsistent design choices on Apple's side. But let's get back to the results... In the code, we have for instance:

And the result is:

All in all, quite cool, simple to understand, manipulate, and even extend (on both the XUL and Cocoa side). Was fun to implement

Bon, soyons clairs, Fillon a fait très fort. Il n'est évidemment ni blanchi ni moins ridicule, mais il a baisé tout son parti - et des millions d'électeurs avec - dans les grandes largeurs encore...

1. la manifestation du Trocadéro a été sinon organisée du moins très largement soutenue et investie par Sens Commun, le faux-nez politique de la Manif pour Tous, aux idées bien nauséabondes ; ce sont donc en grande partie les ultra-Fillonistes qui sont venus le soutenir, et pas monsieur et madame tout-le-monde
2. il n'y évidemment jamais eu 200 et encore moins 300 mille personnes au Trocadéro. Cela n'enlève rien à un rassemblement de déjà 30 à 40 mille personnes en quelques jours, mais la tentation pipotage à la soviétique, c'est vraiment risible.
3. personne n'a annoncé le suicide de son épouse ; ce type ment comme il respire.
4. Sarkozy a baisé Juppé ; il a donné des signaux - ou a fait raconter qu'il avait donné des signaux - de ras-le-bol mou mais dans un autre temps a continué à soutenir Fillon, mollement également. Il a joué l'attente, pas l'implication.
5. le Comité Politique réuni lundi soir n'est pas le Bureau Politique de LR ; c'est un machin, créé et voulu par Fillon lui-même au lendemain de sa victoire à la Primaire. Il est donc principalement composé de soutiens sans faille à sa personne, plus quelques autres qui ne voudront pas apparaître comme les fossoyeurs du parti. Ce sont de plus tous des gens qui espèrent un retour de gamelle si Fillon, par miracle, était élu.
6. rien, absolument rien dans les statuts de LR ne permet de démettre le candidat choisi par la Primaire. Il a le titre, le mandat et le pognon. Il est tellement obtus qu'il ira en justice si LR tente quelque chose contre lui.
7. François Baroin déteste Juppé et Sarkozy n'aime pas Juppé non plus ; ils préfèrent donc un Fillon qui plante LR qu'un Juppé qui gagne. C'est hallucinant, mais c'est comme ça.
8. de toute manière, entre Baroin/Sarko qui n'aiment pas Juppé et Fillon qui aurait tout fait pour le plomber s'il avait repris le flambeau, Juppé ne pouvait pas plus rassembler son propre camp que Fillon. La défaîte était garantie.
9. et puis de toute manière, trop de choses dans le programme de Fillon hérissent le poil de Juppé ; il n'aurait jamais pu porter ses idées telles quelles.
10. ce n'est pas la girouette qui tourne, c'est le vent. Les Larcher, Pécresse, Jacob et autres qui hurlaient au loup dimanche matin et qui font le dos rond lundi soir.... Ils ne voient même pas l'image lamentable qu'ils laissent à la population.
11. les militants qui ne veulent plus tracter parce qu'ils se font insulter sur les marchés, les électeurs qui râlent, rien à foutre ; ils feront ce qu'on leur dit, point.
12. j'attends avec impatience de voir ce que vont faire les Centristes. Vont-ils avoir un peu de courage politique ou vont-ils faire volte-face et se rallier à nouveau à Fillon ?

Tout cela est minable, pathétique. Fillon sera mis en examen le 15 mars. Son épouse, ses enfants, Ladreit de Lacharrière et son remplaçant à l'Assemblée peut-être également. Il sera cerné par les affaires de tous côtés. Il va exploser son parti à l'élection, mais il ira quand même parce que cet homme a dépassé son niveau de Peter mais ne peut ni ne veut le voir.

Remarquez, pendant ce temps, les derniers Hollandais s'apprêtent à soutenir Macron, détruisant ce qu'il reste du Parti Socialiste pendant que le candidat officiel du Parti Socialiste a passé cinq ans à taper sur le programme du Président de la République issu du même Parti Socialiste.

Le PS n'existe plus et va se vautrer dans les grandes largeurs. Le grand parti de droite n'existe plus et va se vautrer dans les grandes largeurs. Macron a raison, il est temps de lancer autre chose mais attention à l'instabilité parlementaire qui guette.

Donc Fillon tient à son chiffre de 200 000 quand tout montre qu'il ne peut y avoir eu plus de 45 000 personnes à son rassemblement et raconte qu'une chaîne télé a annoncé le suicide de sa femme. Ah. Laquelle et quand ? C'est totalement introuvable. Si cela est arrivé, c'est un media même pas secondaire. Il baratine, c'est juste pas croyable. Ce type n'est juste pas qualifié pour être président.

En fait, c'est @meriadeck qui a probablement la meilleure explication :

François Fillon a dû mal comprendre : les médias ont parlé du suicide de sa campagne, pas de sa compagne.

— Meriadeck (@Meriadeck) 5 mars 2017

I am migrating a rough ~9000 lines of Swift 2 code to Swift 3. So really a small thing. And this is a mess of epic magnitude; the time needed to do that is not counted in hours but in days. Even if Swift is beyond 1.0, nothing seems stabilized. Some naming choices are totally ridiculous, unintuitive, painful to remember. Worse, they sometimes drastically change between two versions of Swift.

The whole naming thing of parameters is totally crazy. Let's take the example of some removeAtIndex() in Obj-C. The prototype for that in Swift 3 would be remove(at: index). That's über-cool when you read the prototype. But in your code, you have very little chance to have your parameter named 'index'. For instance remove(at: currentEntryRef). And bam, you've lost the connection to the Obj-C function. Most of my own functions end up with a leading underscore in front of each parameter...

François Fillon vient donc de publier plusieurs documents sur son patrimoine et ses revenus. Ils sont très intéressants mais posent plein de questions.

• je note que j'avais évalué les revenus du couple Fillon en 2013 à 557 069€. Selon Fillon, ils sont donc de 559 784€. Reconnaissez que je n'étais pas loin
• entre 2012 et 2016 (cette dernière année est une estimation selon les documents publiés), les revenus déclarés pour le couple sont de 1 610 846€ (je dis bien un million six cent dix mille huit cent quarante-six euros)
• or l'ensemble des comptes du couple représente un total de 109 303€, dont seulement 72 367€ mobilisables immédiatement
• or rien qu'en impôt sur le revenu, et même avec un dernier enfant à charge, impôt foncier et local, les sommes à payer annuellement sont énormes. Voici un tableau des revenus et des impôts estimés :

année	Revenus déclarés du couple	Impôt sur le revenu estimé sans tenir compte des réductions diverses 2,5 parts (un dernier enfant mineur à charge)
2012	184 982€	47 249€
2013	559 784€	212 968€
2014	247 151€	72 760€
2015	343 656€	environ 114 000€
2016	275 000€ (estimé)	84 179€

Je suis désolé mais cela semble ne pas coller. Entre les sommes gagnées, les sommes payées en imposition (rien que l'IR) et ce qu'il y a sur les comptes déclarés, je ne comprends même pas comment ils arrivent à payer l'impôt sur le revenu. Pour mémoire, nous finissons de payer l'IR sur les revenus de 2015. Ils ont donc environ en ce moment 38 000€ à sortir à chaque tiers provisionnel. Et chaque mois, François Fillon seul ramène sur compte près de 35 000 €. Où est la différence ? Il me semble qu'il manque de l'argent, beaucoup d'argent, énormément d'argent. Est-ce que François Fillon a un train de vie monumental et claque tout ? Ce n'est pas l'intérêt d'emprunt à 639€ par mois qui consomme tout ça.

Je mets n conditionnels à tout ça, avec n grand. Je souhaite juste comprendre et pour l'instant, je ne comprends pas du tout.

Mise à jour mardi 7 février 9h40 : on me signale que l'indemnité de frais de représentation parlementaire pourrait ne pas être imposable, ce qui expliquerait qu'il puisse plus aisément payer son IR. C'est une bonne remarque... mais également une très mauvaise remarque pour M. Fillon ! Dans ce cas, cela signifierait que la part de ses revenus lui restant après impôts est très nettement plus significative qu'estimé plus haut. Et donc la question d'origine est d'autant plus valide : où est l'argent ?

Ce qui suit est un verbatim. Pas de moi.

Tu ne comprends pas. En psychologie, le déni, c'est la forme ultime du complexe d'infériorité d'une part et de la dette à autrui d'autre part. Fillon n'aurait pas pu adopter une meilleure stratégie parce que d'une part il - et personne dans son équipe - n'est capable de voir une meilleure stratégie mais aussi parce que Fillon a toujours été un second couteau : d'abord de Le Theule, ensuite de Séguin, ensuite il s'est rapproché de Sarkozy uniquement quand il est devenu certain que Sarkozy gagnerait l'élection. Sarkozy se marrait même en le montrant du doigt à des journalistes « vous avez vu ? J'ai gagné plein de nouveaux amis, récemment ». Séguin et Sarko sont des grands, des immenses colériques, et Sarkozy a humilié son premier ministre Fillon pendant cinq ans et il a tenu au point de s'en bousiller la santé. S'il renonce maintenant, c'est son niveau de Peter et il montre ce qu'il a toujours été, un second rôle, il revient à un second rôle. Il en est incapable. C'est ça la mécanique du déni.

Long looooong ago, I wrote a deep review of the XHTML 2.0 spec that was one of the elements that led to the resuming of the HTML activity at the W3C and the final dismissal of XHTML 2.0. 

Long ago, I started a similar effort on EPUB that led to Dave Cramer's EPUB Zero. It's time (fr-FR) to draw some conclusions.

This document is maintained on GitHub and accepting contributions.

Daniel Glazman

OCF

1. EPUB publications are not "just a zip". They are zips with special constraints. I question the "mimetype file in first uncompressed position" constraint since I think the vast majority of reading systems don't care (and can't care) because most of the people creating EPUB at least partially by hand don't know/care. The three last contraints (zip container fields) on the ZIP package described in section 4.2 of the spec are usually not implemented by Reading Systems.
2. the container element of the META-INF/container.xml file has a version attribute that is always "1.0", whatever the EPUB version. That forces editors, filters and reading systems to dive into the default rendition to know the EPUB version and that's clearly one useless expensive step too much.
3. having multiple renditions per publication reminds me of MIME multipart/alternative. When Borenstein and Freed added it to the draft of RFC 1341 some 25 years ago, Mail User Agents developers (yours truly counted) envisioned and experimented far more than alternatives between text/html and text/plain only. I am under the impression multiple renditions start from the same good will but fail to meet the goals for various reasons:
   1. each additional rendition drastically increases the size of the publication...
   2. most authoring systems, filters and converters on the market don't deal very well with multiple renditions
   3. EPUB 2 defined the default rendition as the first rendition with a application/oebps-package+xml  mimetype while the EPUB 3 family of specs defines it as the first rendition in the container
   4. while a MIME-compliant Mail User Agent will let you compose a message in text/html and output for you the multipart/alternative between that text/html and its text/plain serialization, each Publication rendition must be edited separately.
   5. in the case of multiple renditions, each rendition has its own metadata and it's then legitimate to think the publication needs its own metadata too. But the META-INF/metadata.xml file has always been quoted as "This version of the OCF specification does not define metadata for use in the metadata.xml file. Container-level metadata may be defined in future versions of this specification and in IDPF-defined EPUB extension specifications." by all EPUB specifications. The META-INF/metadata.xml should be dropped.
   6. encryption, rights and signatures are per-publication resources while they should be per-rendition resources.
4. the full-path attribute on rootfile elements is the only path in a publication that is relative to the publication's directory. All other URIs (for instance in href attributes) are relative to the current document instance. I think full-path should be deprecated in favor of href here, and finally superseded by href for the next major version of EPUB.
5. we don't need the mimetype attribute on rootfile elements since the prose of EPUB 3.1 says the target of a rootfile must be a Package Document, i.e. an OPF file... If EPUB 2 OCF could directly target for instance a PDF file, it's not the case any more for OCF 3.
6. absolute URIs (for instance /files/xhtml/index.html with a leading slash, cf. path-absolute construct in RFC 3986) are harmful to EPUB+Web convergence
7. if multiple renditions are dropped, the META-INF/container.xml file becomes useless and it can be dropped.
8. the prose for the META-INF/manifest.xml makes me wonder why this still exists: "does not mandate a format", "MUST NOT be used". Don't even mention it! Just say that extra unspecified files inside META-INF directory must be ignored (Cf. OCF section 3.5.1) , and possibly reserve the metadata.xml file name, period. Oh, and a ZIP is also a manifest of files...
9. I am not an expert of encryption, signatures, XML-ENC Core or XML DSIG Core, so I won't discuss encryption.xml and signatures.xml files
10. the rights.xml file still has no specified format. Strange. Cf. item 8 above.
11. Resource obfuscation is so weak and useless it's hilarious. Drop it. It is also painful in EPUB+Web convergence.
12. RNG schemas are not enough in the OCF spec. Section 3.5.2.1 about container.xml file for instance shouls have models and attribute lists for each element, similarly to the Packages spec.
13. not sure I have ever seen links and link elements in a container.xml file... (Cf. issue #374). The way these links are processed is unspecified anyway. Why are these elements normatively specified since extra elements are allowed - and explicitely ignored by spec - in the container?

Packages

1. a Package consists of one rendition only.
2. I have never understood the need for a manifest of resources inside the package, probably because my own publications don't use Media Overlays or media fallbacks.
3. fallbacks are an inner mechanism also similar to multipart/alternative for renditions. I would drop it.
4. I think the whole package should have properties identifying the required technologies for the rendition of the Package (e.g. script), and avoid these properties on a per-item basis that makes no real sense. The feature is either present in the UA for all content documents or for none.
5. the spine element represent the default reading order of the package. Basically, it's a list. We have lists in html, don't we? Why do we need a painful and complex proprietary xml format here?
6. the name of the linear attribute, that discriminates between primary and supplementary content, is extremely badly chosen. I always forget what really is linear because of that.
7. Reading Systems are free, per spec, to completely ignore the linear attribute, making it pointless from an author's point of view.
8. I have never seen the collection element used and I don't really understand why it contains link elements and not itemref elements
9. metadata fun, as always with every EPUB spec. Implementing refines in 3.0 was a bit of a hell (despite warnings to the EPUB WG...), and it's gone from 3.1, replaced by new attributes. So no forwards compatbility, no backwards compatibility. Yet another parser and serializer for EPUB-compliant user agents.
10. the old OPF guide element is now a html landmarks list, proving it's feasible to move OPF features to html
11. the Navigation Document, an html document, is mandatory... So all the logics mentioned above could be there.
12. Fixed Layout delenda est. Let's use CSS Fragmentation to make sure there's no orphaned content in the document post-pagination, and if CSS Fragmentation is not enough, make extension contributions to the CSS WG.
13. without 3.0 refines, there is absolutely nothing any more in 3.1 preventing Package's metadata to be expressed in html; in 3.0, the refines attribute was a blocker, implying an extension of the model of the meta html element or another ugly IDREF mechanism in html.
14. the prefix attribute on the package element is a good thing and should be preserved
15. the rendition-flow property is weird, its values being paginated, scrolled-continuous, scrolled-doc and auto. Where is paginated-doc, the simplest paginated mode to implement?
16. no more NCX, finally...
17. the Navigation Document is already a html document with nav elements having a special epub:type/role (see issue #941), that's easy to make it contain an equivalent to the spine or more.

Content Documents

1. let's get rid of the epub namespace, please...

Media Overlays

1. SMIL support across rendering engines is in very bad shape and the SMIL polyfill does not totally help. Drop Media Overlays for the time being and let's focus on visual content.

Alternate Style Tags

1. terrible spec... Needed because of Reading Systems' limitations but still absolutely terrible spec...
2. If we get rid of backwards compatibility, we can drop it. Submit extensions to Media Queries if needed.

On the fly conclusions

1. backwards compatibility is an enormous burden on the EPUB ecosystem
2. build a new generation of EPUB that is not backwards-compatible
3. the mimetype file is useless
4. file extension of the publication MUST be well-defined
5. one rendition only per publication and no more links/link elements
6. in that case, we don't need the container.xml file any more
7. metadata.xml and manifest.xml files removed
8. we may still need encryption.xml, signatures.xml and rights.xml inside a META-INF directory (or directly in the package's root after all) to please the industry.
9. application/oebps-package+xml mimetype is not necessary
10. the EPUB spec evolution model is/was "we must deal with all cases in the world, we move very fast and we fix the mistakes afterwards". I respectfully suggest a drastic change for a next generation: "let's start from a low-level common ground only and expand slowly but cleanly"
11. the OPF file is not needed any more. The root of the unique rendition in a package should be the html Navigation Document.
12. the metadata of the package should be inside the body element of the Navigation Document
13. the spine of the package can be a new nav element inside the body of the Navigation Document
14. intermediary summary: let's get rid of both META-INF/container.xml and the OPF file... Let's have the Navigation Document mandatorily named index.xhtml so a directory browsing of the uncompressed publication through http will render the Navigation Document.
15. let's drop the Alternate Style Tags spec for now. Submission of new Media Queries to CSS WG if needed.
16. let's drop Media Overlays spec for now.

CONCLUSION

EPUB is a monster, made to address very diverse markets and ecosystems, too many markets and ecosystems. It's weak, complex, a bit messy, disconnected from the reality of the Web it's supposed to be built upon and some claim (link in fr-FR) it's too close to real books to be disruptive and innovative.

I am then suggesting to severe backwards compatibility ties and restart almost from scratch, and entirely and purely from W3C Standards. Here's the proposed result:

---

1. E0 Publication

A E0 Publication is a ZIP container. Files in the ZIP must be stored as is (no compression) or use the Deflate algorithm. File and directory names must be encoded in UTF-8 and follow some restrictions (see EPUB 3.1 filename restrictions).

The file name of a E0 Publication MUST use the e0 file extension.

A E0 Publication MUST contain a Navigation Document. It MAY contain files encryption.xml, signatures.xml and rights.xml (see OCF 3.1 for more information). All these files must be placed directly inside the root of the E0 Publication.

A E0 Publication can also contain Content Documents and their resources.

Inside a E0 Publication, all internal references (links, anchors, references to replaced elements, etc) MUST be strictly relative. With respect to section 4.2 of RFC 3986, only path-noscheme and path-empty are allowed for IRIs' relative-part. External references are not restricted.

2. E0 Navigation Document

A E0 Navigation Document is a html document. Its file name MUST be index.xhtml if the document is a XML document and index.html if it it is not a XML document. A E0 Publication cannot contain both index.html and index.xhtml files.

A E0 Navigation Document contains at least one header element (for metadata) and at least two nav html elements (for spine and table of contents) in its body element.

2.1. E0 Metadata in the Navigation Document

E0 metadata are designed to be editable in any Wysiwyg html editor, and potentially rendered as regular html content by any Web browser.

E0 metadata are expressed inside a mandatory header html element inside the Navigation Document. That element must carry the "metadata" ID and the vocab attribute with value "http://www.idpf.org/2007/opf". All metadata inside that header element are then expressed using html+RDFa Lite 1.1. E0 metadata reuse EPUB 3.1 metadata and corresponding unicity rules, expressed in a different way.

Refinements of metadata are expressed through nesting of elements.

Example:

<header id="metadata"
        vocab="http://www.idpf.org/2007/opf">
  <h1>Reading Order</h1>
  <ul>
    <li>Author:
        <span property="dc:creator">glazou
         (<span property="file-as">Glazman, Daniel</span>)</span></li>
    <li>Title:
        <span property="dc:title">E0 Publications</span></li>
  </ul>
</header>

The mandatory title element of the Navigation Document, contained in its head element, should have the same text contents than the first "dc:title" metadata inside that header element.

2.2. E0 Spine

The spine of a E0 Publication is expressed in its Navigation Document as a new nav element holding the "spine" ID. The spine nav element is mandatory.

See EPUB 3.1 Navigation Document.

2.3. E0 Table of Contents

The Table of Contents of a E0 Publication is expressed in its Navigation Document as a nav element carrying the "toc" ID. The Table of Contents nav element is mandatory.

See EPUB 3.1 Navigation Document.

2.4. E0 Landmarks

The Landmarks of a E0 Publication is expressed in its Navigation Document as a nav element carrying the "landmarks" ID. The Landmarks nav element is optional.

See EPUB 3.1 Navigation Document.

2.5. Other nav elements

The Navigation Document may include one or more nav elements. These additional nav elements should have an role attribute to provide a machine-readable semantic, and must have a human-readable heading as their first child.

IDs "metadata", "spine" , 'landmarks" and "toc" are reserved in the Navigation Document and must not be used by these extra nav elements.

2.6. Example of a Navigation Document

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="content-type">
    <title>Moby-Dick</title>
  </head>
  <body>
    <header id="metadata"
            vocab="http://www.idpf.org/2007/opf">
      <ul>
        <li>Author:
          <span property="dc:creator">Herman Melville
            (<span property="file-as">Melville Herman</span>)</span></li>
        <li>Title:
            <span property="dc:title">Moby-Dick</span></li>
	<li>Identifier:
	    <span property="dc:identifier">glazou.e0.samples.moby-dick</span></li>
	<li>Language:
	    <span property="dc:language">en-US</span></li>
	<li>Last modification:
	    <span property="dcterms:modified">2017-01-17T11:16:41Z</span></li>
	<li>Publisher:
	    <span property="dc:publisher">Harper & Brothers, Publishers</span></li>
	<li>Contributor:
	    <span property="dc:contributor">Daniel Glazman</span></li>
      </ul>
    </header>

    <nav id="spine">
      <h1>Default reading order</h1>
      <ul>
	<li><a href="cover.html">Cover</a></li>
	<li><a href="titlepage.html">Title</a></li>
	<li><a href="toc-short.html">Brief Table of Contents</a></li>
	...
      </ul>
    </nav>

    <nav id="toc" role="doc-toc">
      <h1>Table of Contents</h1>
      <ol>
	<li><a href="titlepage.html">Moby-Dick</a></li>
	<li><a href="preface_001.html">Original Transcriber’s Notes:</a></li>
	<li><a href="introduction_001.html">ETYMOLOGY.</a></li>
	...
      </ol>
    </nav>
  </body>
</html>

3. Directories

A E0 Publication may contain any number of directories and nested directories.

4. E0 Content Documents

E0 Content Documents are referenced from the Navigation Document. E0 Content Documents are html documents.

E0 Content Documents should contain <link rel="prev"...> and <link rel="next"...> elements in their head element conformant to the reading order of the spine present in the Navigation Document. Content Documents not present in that spine don't need such elements.

The epub:type attribute is superseded by the role attribute and must not be used.

5. E0 Resources

E0 Publications can contain any number of extra resources (CSS stylesheets, images, videos, etc.) referenced from either the Navigation Document or Content Documents.

I feel the need to add context to the contents of my previous article about the architecture of the royal Castle of Chambord, probably one of the most beautiful castles in France. It's commonly accepted that the castle was built based on a grid layout, and the french version of Wikipedia has some details about that design:

Plan illustrant le concept initial du Château - Monsieur W, CC0

Unfortunately, this theory is really partial since it does not explain many, too many choices:

• on the grid above, the dungeons seems carefully aligned with the grid, and the center of the towers should then be perfectly aligned with the sides of the main body of the castle. It is very clear from the map and de visu that it's not the case. The main body of the castle eats lets than a fourth of each tower and, again, it's extremely visible if you pay a real-life visit to the castle: the two angles between a tower's walls and the main body are less than 90°.
• this does not explain how the size of the main body of the castle was chosen
• the grid above works only if the center column and row are slightly larger than the other ones
• it does not explain the obvious ratios between the castle itself and its enclosure
• with my Standards freak's eye, there are too many things left unspecified

So I think the way the castle was designed is different and I think the WHOLE basis for it is the diameter of the towers/enclosure towers. Once that value is specified, the whole castle can be entirely derived from very basic operations that are so simple a rule and a compass are enough to draw the whole thing.

Before diving into the architecture of the main body of the castle itself, we must see that the enclosure of the castle (without towers) is very precisely a scale(3, 2) of the main body of the castle (without towers). So if we can show that the main body of the castle itself is determined solely from the diameter of the towers, it will imply the whole architecture, from enclosure to main body will rely on a single length only !

Let's do that here...

If you take the result of that experiment and overlay it over the map of the main body of the castle, it's a perfect and precise match. Since the enclosure is trivial to determine from here, the whole plan relies, as expected, on a single value : the diameter of the towers.

Chambord is a mathematical construct, with the computation of a square enclosing a pavement of 5 circles, a placement of 4 of the same circles around the square and then a trivial scaling of that construct to build the enclosure. I'm pretty sure we could also find a scale ratio between the height of the enclosure and the height of the main body of the castle.

All in all, the grid system quoted above seems to me approximative, and most probably mistaken.