By glazou on Saturday 22 December 2012, 20:34 - Microsoftisms
Here is what I wrote about Microsoft Expression Web five and a half years ago. I have worked almost all my professionnal life on markup-based Wysiwyg editors. And because the this is a small community working on very, very complex apps, I was really sad yesterday to read that Microsoft Expression Web is no more. To the people who originally built that application and the Expression Web team at Microsoft, my sincere regrets and wishes for your own future.
By glazou on Thursday 29 November 2012, 15:01 - Mozilla
I'm the guilty one for the resizing handles (around tables, positioned elements and images) in Gecko's editor. It was a decade ago... I wanted a JavaScript-based implementation but Netscape's management wanted a C++ one to have the whole thing embeddable into an AOL project that you never heard of and never saw the light. Because of that, it's hardly manageable/extensible today and I decided to drop it for BlueGriffon (that's just a boolean to set to false on the editor) and switch to my own JavaScript-based implementation. I spent a short while on that last week-end and here's the first result (or see embedded video below). As far as I know, it's a first for the editor (I mean Gecko's).
Last detail, this should work even if CSS transforms apply to the table. Unfortunately, I filed a bug blocking it earlier today.
By glazou on Saturday 24 November 2012, 12:25 - Standards
Method-Draw is a superb fork of the popular web-based SVG editor SVG Edit. You can try it here and the project is hosted on github here.
As a reminder, BlueGriffon embeds SVG Edit. As soon as I have time for that, I'll look more closely at Method-Draw to see if it could replace SVG Edit in BlueGriffon since I find its UI and the UX it induces quite nice.
So this add-on adds a new button to the formatting toolbar of message composition windows (the π button at the right-hand side of the main window), a new menu entry under Insert and both open a dialog allowing to insert/edit MathML through AsciiMathML. Hope you'll find it useful, it's available from here and it's not a 1.0 yet.
By glazou on Thursday 25 October 2012, 14:46 - Mozilla
I have fixed two too well hidden bugs in BlueGriffon EPUB Edition and, while I was there, I added an editing view for CSS stylesheets directly from the list of files. You can download that new version from its web site. Many thanks to @studiowalrus for the feedback.
By glazou on Tuesday 23 October 2012, 10:18 - Mozilla
I am happy and proud to let you know I just released BlueGriffon EPUB Edition, the very first Wysiwyg cross-platform editor for EPUB2 and EPUB3 ebooks offering full UI-based control on EPUB packages, including all of EPUB2 and EPUB3 metadata. A more complete list of features and screenshots are available. Implemented with a permanent requirement of conformance to the IDPF specifications, it took more than a year to emerge from the original BlueGriffon Web editor because it's not only some light zip-package management over (x)html editing. EPUB metadata are complex to author and edit, very complex, and it's not a surprise to me if BlueGriffon EPUB Edition is alone right now in that segment of the market.
On the Mozilla side, this is quite good news I must say. Most current EPUB readers and authoring tools are based on WebKit or the rendering engine inside Apple Pages. BlueGriffon EPUB Edition shows that Gecko is a 100% viable solution as a rendering engine for EPUB. It also shows that XUL is still a superb technology allowing very complex consumer- or business-oriented applications.
To celebrate the launch of BlueGriffon EPUB Edition, a discount coupon is available until the 25th 00:00am Pacific time, giving you a 25€ discount per license purchased.
By glazou on Tuesday 18 September 2012, 18:45 - General
Dear Anil, we received your stamps _today_. The envelope does not tell us when you send it but we're sure it's months ago ; it suffered a bit but all the stamps are ok. Thanks you so much !!! Michel and Gabriel Glazman.
This file, if present, must be used for container-level metadata. This
version of the OCF specification does not specify any container-level
metadata.
And the other sections of the OPF file do not contain metadata but a manifest, a spine and other stuff but no metadata...
I think - but I can't be sure - it in fact means:
Cardinality: as a primary expression (i.e. applies to the Publication): zero or more; as a subexpression (i.e. refining a primary expression or another subexpression: zero or one for the refined expression or subexpression
Anyway, the original prose is very badly worded, to say the least. Carefully reading the spec, I have no idea what are "other metadata" so there is at least an important definition (sic) here that remains undefined...
By glazou on Friday 14 September 2012, 12:31 - Standards
Remember when I said the following?
any mechanism based on ID/IDREF introduces an extra keyword, the ID of the element ("mainauthor"
here)... Asking a non-techie user to provide an ID is clearly
suboptimal in terms of UX. That means the editing environment should
pick one ID for the author, at the risk of using a human language not
understood by the package's author or even a meaningless random ID.
Seems the situation is even worse than I expected... The EPUB3 Publications specification explicitly allows chains of subexpressions through ID/REF mechanisms and refines attributes. I guess it'll be clearer with this example:
<dc:identifier id="bookID"> B64F547F-F2D1-4ACE-B8D2-D164785CDEB8 </dc:identifier> <!-- meta element below refines the dc:identifier element above --> <meta refines="#bookID" property="meta-auth" id="meta-authority1">My metadata Authority</meta> <!-- link element below refines the meta element above... --> <link refines="#meta-authority1" rel="xml-signature" href="../META-INF/signature.xml#Signature"/>
One ID/IDREF is already hard enough to deal with in UI but a chain?!? I can find one single word only to describe such a mechanism in a Standard oriented towards creation of visual products, i.e. oriented towards Wysiwyg-ness and nicely composed UIs: ridiculous. EPUB3 metadata are clearly a deep weakness in the EPUB3 format because of the incredible complexity they introduce in editing environments. Honestly, I am not sure to implement this, it would drastically uglify a UI that is already complex enough.
By glazou on Monday 27 August 2012, 15:39 - Standards
I said a few days ago that validation of EPUB3 Content Documents is impossible. That's actually incorrect and I apologize for that. The PUB3 Content Documents spec normatively cites a RelaxNG schema for XHTML5 markup and dataypes. Still, I have no idea from reading the spec what flavor or xhtml5 it represents... I'm left with a RNG to understand if a given html5 element is implemented or not, and how, in EPUB3. Hum.
By glazou on Saturday 25 August 2012, 14:10 - Standards
Validation of meta elements in EPUB3 triggers a few surprises... In fact, that's not the meta elements themselves, it's the properties they carry. Let me explain:
EPUB3 meta elements carry a property attribute
a property is a keyword optionally preceded by a property vocabulary prefix and a colon
EPUB3 Media Overlays use the reserved media prefix mapped to namespace http://www.idpf.org/epub/vocab/overlays/#
the Media Overlays says the media:duration property has a cardinality of "exactly one for the Publication and for each Media Overlay"
In fact, that's quite painful and costly to test in the following case:
suppose the namespace above is declared (yes, I know it's already reserved but it's not forbidden to do it !!!) on the package's prefix attribute with prefix foo
suppose we have one <meta property="media:duration"> in the OPF for the Publication
but also a <meta property="foo:duration"> for the same value...
that's invalid per spec, see the last item of the list above
You can't compare the prefixes, that's not enough. You really need to rely on URIs and that's where validation is expensive.
Conclusion: Media Overlays 3.0 have been released with EPUB3. The associated media prefix should be dropped and its related properties should be prefixless in EPUB3. If the issue is the media:narrator property too close to a value in another property vocabulary, it should be changed.
By glazou on Tuesday 21 August 2012, 15:17 - Standards
EPUB3 is based on the xml serialization of HTML5. When I say HTML5, I really mean the W3C version. But there is a problem ; that also happens with many other specs normatively referenced by EPUB3 but let's focus on HTML5 right now: the link to the HTML5 normative reference has for href http://www.w3.org/TR/html5/ . In other terms, the last version (WD, LCWD, CR, PR, REC) published by W3C.
What's the version to consider for the implementation of an EPUB3 reader or editor? I have no idea. What has changed between the time the HTML5 WD was normatively referenced and now? I have no idea. What if for instance an "at-risk" feature is dropped in a future WD of the spec? I have no idea.
This is not only a theoretical issue, it has a deep and immediate practical impact: validation of the Content Documents inside an EPUB3 ebook is impossible. More globally, full validation of an EPUB3 package is then impossible.
The prefix attribute definition is unchanged, but the attribute is defined to be in the namespace http://www.idpf.org/2007/ops when used in Content Documents.