Announcing Project Mortar

[Johnny Stenback]

In order to enable stronger focus on advancing the Web and to reduce
the complexity and long term maintenance cost of Firefox, and as part
of our strategy to remove generic plug in support, we are launching
Project Mortar.

Project Mortar seeks to reduce the time Mozilla spends on technologies
that are required to provide a complete web browsing experience, but
are not a core piece of the Web platform. We will be looking for
opportunities to replace such technologies with other existing
alternatives, including implementations by other browser vendors.

In order to keep costs low, we may use APIs internally that are not
considered web standards. These APIs will not be exposed to the web.
Solutions that both reduce our support cost, achieve the desired user
experience, and make use of web standards will be preferred.

The project will start by investigating how Firefox handles PDF
rendering followed by looking into lower cost approaches to providing
Flash support as it’s usage continues to decrease. Project Mortar is
currently investigating using the minimum set of Pepper APIs needed to
support the PDFium library and the Pepper Flash plugin. If successful,
this work will allow us to completely remove NPAPI support from
Firefox once NPAPI is disabled for general plugin use.

Keep an eye on https://wiki.mozilla.org/Mortar_Project for status and
future updates for this project.

- jst

[Reed Loden]

How does this impact the PDF.js project? Is that project considered dead
(assuming PDFium will replace it)? Or will they somehow work together?

~reed

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org <javascript:;>
> https://lists.mozilla.org/listinfo/dev-planning
>

[Johnny Stenback]

This should have no real impact on PDF.js as a standalone project. If
our efforts on using PDFium in Firefox gives us a bigger bang for the
buck, Firefox will most likely switch to PDFium and no longer use
PDF.js though. I don't see why PDF.js wouldn't continue to live on and
continue to be used by others.

- jst

>> https://lists.mozilla.org/listinfo/dev-planning

[Gervase Markham]

On 30/09/16 08:48, Johnny Stenback wrote:
> Flash support as it’s usage continues to decrease. Project Mortar is
> currently investigating using the minimum set of Pepper APIs needed to
> support the PDFium library and the Pepper Flash plugin.

As people like roc have pointed out in the past:
http://robert.ocallahan.org/2013/05/blink-pnacl-and-standards.html
Pepper is not a documented standard, and is tied to Chrome internals.
Are we prepared to have to keep tweaking our implementation to match
theirs, and to whatever contortions are needed to the inside of our
product so that it works enough like theirs for the APIs to make sense?

Also, you say "minimum set" - what is Pepper used for apart from PDFium
and Flash? Surely to get those to work, you basically need to implement
everything?

Gerv

[Peter Van der Beken]

On 30/09/16 19:32, Gervase Markham wrote:
> http://robert.ocallahan.org/2013/05/blink-pnacl-and-standards.html

As a sidenote, I just want to make it clear that we are not implementing
PNaCl, or exposing the Pepper APIs to the web.

> Are we prepared to have to keep tweaking our implementation to match
> theirs, and to whatever contortions are needed to the inside of our
> product so that it works enough like theirs for the APIs to make sense?

We will do what is necessary for API compatibility so that PDFium and
Flash will work. I think that will be less complicated than you make it
sound, but we'll see.

> Also, you say "minimum set" - what is Pepper used for apart from PDFium
> and Flash? Surely to get those to work, you basically need to implement
> everything?

No, these two plugins combined still only use a subset of the whole
Pepper API set. I don't personally know what the other APIs are used
for, but we have no plans to implement them.

Peter

[Gervase Markham]

On 30/09/16 14:53, Peter Van der Beken wrote:
> On 30/09/16 19:32, Gervase Markham wrote:
>> http://robert.ocallahan.org/2013/05/blink-pnacl-and-standards.html
>
> As a sidenote, I just want to make it clear that we are not implementing
> PNaCl, or exposing the Pepper APIs to the web.

Sure; I wasn't suggesting that. I realise roc's post covered more topics
than the one I was indicating it was relevant to.

Gerv

[Steve Wendt]

On 9/30/2016 2:09 AM, Reed Loden wrote:

> How does this impact the PDF.js project? Is that project considered dead
> (assuming PDFium will replace it)? Or will they somehow work together?

I was going to ask the same about Shumway, but looks like that baby got
knifed a while ago:
http://www.i-programmer.info/news/86-browsers/9473-mozilla-kills-shumway-its-flash-replacement.html

[alexande...@gmail.com]

more of the same stupid waste of resources, yet another pdf viewer in firefox ?..... what for ? .

what are you people doing............?

[seto...@gmail.com]

Totally agree Alexander.

[khag...@gmail.com]

+1, a total waste of effort. For PDF preview PDF.js is more than adequate and Flash is on live support already. Go do something useful for once, like helping with HTML5 input fields that should have been implemented years ago.

[blackl...@gmail.com]

Do not waste resources, pelase!

[Nicholas Nethercote]

On Sat, Oct 1, 2016 at 1:38 PM, <alexande...@gmail.com> wrote:
>>
>> The project will start by investigating how Firefox handles PDF
>> rendering
>

> more of the same stupid waste of resources, yet another pdf viewer in firefox ?..... what for ? .
>
> what are you people doing............?

First of all, please keep your feedback constructive. Insulting
language isn't helpful.

Second, judging by the responses in this thread, the motivation behind
this project isn't clear. I'm not involved with Project Mortar at all,
but I have heard a little about it, so I will try to explain it a bit.
I may not have the details 100% correct, but this is my understanding,
at least for the PDF part.

- Although viewing PDFs in the browser is useful, PDFs are not a
fundamental part of the web. Therefore, Mozilla would like to not have
to spend a lot of effort supporting them.

- Although PDF.js is a really cool project, despite a lot of effort it
still has two significant shortcomings: it is a little on the slow
side, and it doesn't support all PDF functionality, including
form-filling. Fixing those shortcomings would be a lot of work. (PDF
is a *huge* format.)

- PDFium already exists. It is faster than PDF.js and supports more
PDF functionality. One downside of it is that it's written in an unsafe
language, but it can be run in a sandbox which mitigates that.

- Therefore, Mozilla is looking at replacing PDF.js with PDFium. This
has two potential benefits: (a) users will have a better PDF-viewing
experience, and (b) in the long-run it will save effort, which
means Mozilla can expend more effort on core web technologies: HTML,
CSS, JavaScript, etc.

Hopefully that helps clear things up a bit.

Nick

[craig....@gmail.com]

On Sunday, 2 October 2016 23:27:51 UTC+1, Nicholas Nethercote wrote:
>> Although viewing PDFs in the browser is useful, PDFs are not a fundamental part of the web.

Bit of a tangent... PDF's are important for the web, but they are very problematic (e.g. try reading an A4 formatted PDF on a small screen).

If any developers implementing PDF in Firefox are on this list, I would like to discuss how we can move away from PDF's, possibly creating a simple alternative which allows for a HTML/CSS based document to replicate many of PDF's strengths:

https://bugzilla.mozilla.org/show_bug.cgi?id=1237990

https://github.com/craigfrancis/wdoc

Craig

[Mark Rousell]

On 03/10/2016 09:43, craig....@gmail.com wrote:
> On Sunday, 2 October 2016 23:27:51 UTC+1, Nicholas Nethercote wrote:
>>> Although viewing PDFs in the browser is useful, PDFs are not a fundamental part of the web.
>
> Bit of a tangent... PDF's are important for the web, but they are very problematic (e.g. try reading an A4 formatted PDF on a small screen).
>
> If any developers implementing PDF in Firefox are on this list, I would like to discuss how we can move away from PDF's, possibly creating a simple alternative which allows for a HTML/CSS based document to replicate many of PDF's strengths:

Wouldn't this be a case of re-inventing the wheel? Multiple formats that
address this use case quite well (albeit from different perspectives)
already exist: XPS, Mobi, Epub, potentially HTML/CSS itself, as well as
the two web archive formats below.

> https://bugzilla.mozilla.org/show_bug.cgi?id=1237990

This is 'Webpage ZIP as alternative to PDF' but two entrenched formats
already exist to do an equivalent: MHTML (RFC2557) and MAFF
<http://maf.mozdev.org/maff-specification.html>.

I accept that there is no existing format that is precisely the
equivalent of PDF but using HTML/CSS and Zips but, as above, there seem
to be so many existing formats (and, crucially, they are well-supported
formats) that cover what one might want to do with a theoretical new
format in this context that creating a new format and persuading people
to use it seems likely to be a wasted effort. It's risking XKCD 927
<http://www.xkcd.com/927/>.


--
Mark Rousell

[craig....@gmail.com]

Hi Mark,

I also worry about a "XKCD 927", and I spent a lot of time evaluating each of the existing formats because of that.

Overall, none of them address the security, accessibility, or the ease of which the documents can be created/distributed.

And while I did discuss this with the W3C a while ago, they were too focused on creating their own "new standards" (e.g. PWP), all of which have their uses, but didn't actually address the problems in PDF.

I did also had an interesting discussion with someone at Adobe (under NDA), and they are looking at something very similar to this (but also more complicated).

The justification about this file format is at the following URL:

https://github.com/craigfrancis/wdoc

And in response to your suggestions (which I appreciate), I've described why they unfortunately don't work below.

Craig






XPS, aka "Open XML Paper Specification", is a complete XML document format (kind of like OpenDocument and OpenXML), which does get packaged into a ZIP, but requires a ~300 page specification, and uses an XML schema that's unique to it. If you download one of these files from the web, the browser (e.g. Firefox) is not going to be able to display it's contents. And anyone who wants to create an XPS file will either need to learn the specification, or get a program to convert a source document into this format. It also, like PDF, does not support things like media queries, so you have no chance of styling the document to better display on a small screen.

Mobi, Epub, and PWP are focused on books, and are seen by consumers as a file format for publications (not so much reports), where they get saved and opened in their eReaders. These file formats also require extra information such as a manifest file, and certain elements like a table of contents (not good for a single page document). Overall these formats focus on pages of text, rather than anything designed (it can be done, but it's difficult), where they do this to provide features like changing the font, text size, background colour, etc.

HTML/CSS itself, yes, this is what I want - but you cannot simply email a HTML file to someone (even if you inline the CSS/JS/Images). My proposal is simply to use HTML/CSS, but take away the pain of inlining the resources (by simply including them in a ZIP), and applying some restrictions on the document for security reasons (e.g. it must not be allowed to make a request out to the internet, as these are supposed to be atomic/unchanging documents).

MHTML, is also kind of what I'm after - but it's not really implemented in Firefox, the documents are very difficult to create (basically an email format, that inlines the resources), it does not apply any restrictions to the content (so it can make connections to the internet, maybe to download new content, which is a very bad thing), it does not compress the content, and you cannot password protect the documents.

WebArchive, like MHTML, but uses a binary plist file format... so even harder to create.

MAFF, aka "Mozilla Archive Format", like MHTML but better, in that it uses ZIP (so it's easier to create files in this format). But I believe it's only supported in the "Mozilla Archive Format" extension, and I believe it does not apply any restrictions on the file when opening it (must admit, it was over a year ago when I looked at this file format).

[Mark Rousell]

Craig,

First of all I apologise for taking ten days to reply!

On 03/10/2016 17:48, craig....@gmail.com wrote:
> Hi Mark,
>
> I also worry about a "XKCD 927", and I spent a lot of time evaluating each of the existing formats because of that.
>
> Overall, none of them address the security, accessibility, or the ease of which the documents can be created/distributed.
>
> And while I did discuss this with the W3C a while ago, they were too focused on creating their own "new standards" (e.g. PWP), all of which have their uses, but didn't actually address the problems in PDF.
>
> I did also had an interesting discussion with someone at Adobe (under NDA), and they are looking at something very similar to this (but also more complicated).
>
> The justification about this file format is at the following URL:
>
> https://github.com/craigfrancis/wdoc

I accept that no existing format addresses the exact use case that you
have in mind for wdoc, especially taking into consideration the specific
drawbacks that you list of other formats in this context. I also
appreciate that the format you propose has the advantage of relative
simplicity and that most web browsers or mail clients could probably
fairly easily be updated to support it.

One complication would be choosing how wdoc would archive web pages that
make heavy use of Javascript for dynamically placing content. Such pages
often cause print-to-PDF/save-as-PDF and save-as-MHT extensions great
difficulty: The saved result is often quite dissimilar to the original,
dynamically-generated page. As far as I can see, the wdoc format would
have the same difficulty since, if I understand correctly, it would want
to exclude the Javascript from the saved version of the page (or at
least prevent the Javascript from requesting data from outside the wdoc
file). Unless I'm missing something, there'd be no easy solution to this.

Despite the possible issue with saving faithful renderings of
Javascript-heavy web pages, I would probably use the wdoc format if the
support was there. I already use print-to-PDF print drivers and the
UnMHT extension to save archives of web pages and I can tolerate the
Javascript-related rendering issues that these experience, so such
problems should not put me off using wdoc.

Personally, my main concern in terms of "support" would be the existence
of an IFilter
<https://msdn.microsoft.com/en-us/library/bb331575(v=vs.85).aspx#adding_new_file_format>
for the wdoc format so that it could be properly indexed (both content
and metadata) in the Windows Search system. Both PDFs and MHT files are
automatically indexed (both text and metadata) by Window Search.

Good luck with gaining mindshare for the wdoc format. Although it seems
as if it should be relatively simple to implement, I think that its use
case is similar enough to other pre-existing formats to cause people to
reject it to begin with, as I originally did.

If you could write a proof of concept Firefox extension then perhaps
that would help a lot. (It might even be possible to do it in the new
WebExtension system).

--
Mark Rousell

[pwd.m...@yahoo.co.uk]

The long and short of it is that if Mozilla considers PDFs to be part of the core internet experience, invest in making that accessible via the free internet conduit that is Firefox (i.e. extend PDF.js), if it isn't, then PDF.js offers enough functionality to preview PDFs. It's literally that simple.

On Thursday, 13 October 2016, 23:41, Mark Rousell <mark.r...@signal100.com> wrote:


Craig,

First of all I apologise for taking ten days to reply!

On 03/10/2016 17:48, craig....@gmail.com wrote:

> Hi Mark,
>
> I also worry about a "XKCD 927", and I spent a lot of time evaluating each of the existing formats because of that.
>
> Overall, none of them address the security, accessibility, or the ease of which the documents can be created/distributed.
>
> And while I did discuss this with the W3C a while ago, they were too focused on creating their own "new standards" (e.g. PWP), all of which have their uses, but didn't actually address the problems in PDF.
>
> I did also had an interesting discussion with someone at Adobe (under NDA), and they are looking at something very similar to this (but also more complicated).
>
> The justification about this file format is at the following URL:
>
> https://github.com/craigfrancis/wdoc

[Mark Rousell]

On 14/10/2016 02:25, pwd.m...@yahoo.co.uk wrote:
> The long and short of it is that if Mozilla considers PDFs to be part of the core internet experience, invest in making that accessible via the free internet conduit that is Firefox (i.e. extend PDF.js), if it isn't, then PDF.js offers enough functionality to preview PDFs. It's literally that simple.

Well yes, that's true for PDFs but the discussion is about a proposed
new format called wdoc with a different use case to pdf. :-)



--
Mark Rousell

[craig....@gmail.com]

Hi Mark,

While wdoc could archive web pages, the primary focus for me is reports, white papers, manuals, invoices, contracts, bank statements, etc.

As in, where a system/website needs to generate a document for people to read/save/email/print/etc.

Normally these are PDF's, but this is not ideal for end users (see previous email), and they are very difficult to create, with many developers choosing to create a HTML document first, and then passing it through one of the many HTML to PDF convertors (which strip all of the semantics, and typically do a poor job of rendering with CSS)[1].



As to your comments...

Windows Search, if it gets implemented in MS Edge [2], then Microsoft can easily index the content as well, where it would be almost identical to indexing docx files (which is a fairly complex XML file within a ZIP).

I'll try to look at WebExtension, or a general Firefox extension; unfortunately time is a little tight at the moment (due to paying work, such as hacking DOMPDF to generate a PDF in a certain way).

With archiving web pages, I might have to follow up on that in another email if anyone is interested, but you are right, this is a difficult thing to do, and will only be a bit better than the current solutions.

Anyway, thanks for the reply (don't worry about the delay), and for taking your time to read through the proposal.

Craig




[1] HTML to PDF convertors:

https://github.com/dompdf/dompdf
http://wkhtmltopdf.org/
https://www.google.com/?q=html+to+pdf

The Google search really demonstrates the number of "solutions".


[2] https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/11443002-webpage-zip-as-alternative-to-pdf