Re: ConTeXt as a service

[Henning Hraban Ramm <texml@fiee.net>]

> Am 2019-11-23 um 15:14 schrieb Mojca Miklavec <mojca.miklavec.lists@gmail.com>:
> 
> On Sat, 23 Nov 2019 at 13:02, Henning Hraban Ramm wrote:
>>> Am 2019-11-23 um 08:12 schrieb Mojca Miklavec:
>>>> 
>>>> Then you can use one of the online JS editors like CKeditor.\
>>> 
>>> Only if you spend an enormous amount of effort making sure that the
>>> code is properly cleaned up rather than containing a gazillion random
>>> html style tags which you can never reconstruct back into some
>>> structured form.
>>> 
>>> (And yes, my impression is that Massi spent a huge amount of effort in
>>> configuring the editor and cleaning up the mess. My company didn't and
>>> ended up with sometimes literally every word in a sentence using a
>>> different font size or style. They gave up on html + cke pretty soon,
>>> but couldn't be convinced that this was a bad idea upfront.)
>> 
>> Don’t exaggerate. Or maybe your company didn’t think about which tags are really necessary.
>> A proper configuration that doesn’t allow nonsense, even if users paste text from Word documents, is not such a big effort.
> 
> I'm not exaggerating, I would gladly be convinced/proved that I'm
> wrong. How much effort (expressed in hours or days) do you think is
> needed to implement the following?
> (Any existing opensource solution may be used as the basis.)
> 
> My wishlist is not that demanding:
> * allow generating both printable documents on white background, as
> well as black slides with mostly white text (PDF as well as browsable
> HTML website)
> * support advanced mathematical formulas
> * some sections or words do need to have some special markings (for
> example apply some colours or bold/italic; the colour of course needs
> to depend on background colour)
> * tables need to be styled according to white the designer specifies,
> but it should be very easy to change the table style after some months
> * support consistently styled "CAUTION: ..., WARNING: ..., NOTE: ..."
> sections inside the text (make it trivial to change the style of how
> these are printed out after some months)
> * support table of contents, nice front page etc.
> * support vector images for PDFs

Oh, IMO that wishlist is very demanding. I’d say it’s more or less impossible with any HTML editor.

My demands were much less and well controllable:
- no math, no tables
- no images (they were handled differently and attached to the articles)
- only simple markup (bold or italics)
- not even headings (we used single editor instances for every paragraph with single text fields for section headings)
- I added a few special tags, but in the end we hardly ever needed them.

We had different preconfigured types of articles with length and section limits, also dependend on rubric.
The workflow was not automatical: output was InDesign tagged text, i.e. preformatted text that the layouters put together in InDesign, also only working with the right InDesign templates that contained the styles that the articles addressed.
Pictures came in FTP folders with named references to the articles. My client program collected articles from the web application, ads and pictures from the FTP server, preprocessed the ads and images and could also prepare InDesign docs, if they didn’t exist (using AppleScript to control InDesign).
We used single ID documents for every rubric (that way several people could work on one issue) and combined them as a "book" in the end. The ToC was partly automatic (rubrics and page numbers), but manually adapted (layout, pictures etc.).

The whole thing started with the automation of the event calendar – when I took over, they used a single user FileMaker database that got exported with a limited (demo?) version of a plugin; all the formatting was done manually. My colleagues at the printshop needed several days of work for that alone. I made a simple web app (database frontend), and used InDesign’s XML import – importing the calendar needed about an hour, but then it was perfectly formatted, including some icons. On the editors’ side, it was a big time saver that they could copy existing events and there was a simple location/host management. Then the publishers asked if they couldn’t use the same system also for their articles…

When I started my second attempt at the system (replacing PHP and proprietary libraries with a JS/Webix frontend and a Python/Django backend), I was planning to use one editor for whole articles and probably would have run into some of your problems, but the customer didn’t like to spend money and was using my old system for several more years, until the magazine was bought by a bigger publisher…
I was also planning for different backends, i.e. IDML, ConTeXt, LaTeX or any XML output. But I’m always planning a lot.

Sorry for pratting, got nostalgic.

The JS editors I know of allow for custom menus, and it should be easy to setup special divs for these warning sections.
I don’t know any good table or formula editors/plugins, though. I’m not up to date, but I guess with a graphical/“WYSIWYG” tool you’ll never get perfectly structured input and will never be able to address finer details of typography, esp. WRT math.
(Remember what Hans told us about Pragma’s ASCIImath workflow.)

Also, what Massi said. He has more extensive and more current experience than me.

Best, Hraban


___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________