Am 20.11.19 um 18:10 schrieb Henning Hraban Ramm:

Hi!

I’m running ConTeXt on my web server e.g. to generate shipping forms for a customer.

As Hans said, it makes sense to use an asynchronous setup; in my case it’s celery/RabbitMQ behind Django.

You probably need to set a few environment variables: I find HOME, PATH, TEXROOT and TEXMFOS in my setup. I don’t know if you really need all of them, it’s already running for several years… Also your web server process might only run binaries that belong to some user/group like wwwrun.

It won’t work in shared hosting, because you can’t install your own programs.

Generally this is correct. But there are providers such as the Hostsharing cooperative where it is possible to install programs in a shared hosting environment. We do it for years. ;-)

Otherwise: What kind of documentation do you need? Installing ConTeXt on a (web) server is not different from any other Linux system. Calling ConTeXt from a web application is not different from calling any other external program. The rest depends on your setup and web frameworks.

I am very interested in running ConTeXt as a service, too. I am still nurturing the idea of a publishing cooperative for self publishers with a Markdown --> Pandoc --> ConTeXt workflow with a nice web frontend. I hope to make it to the next ConTeXt meeting to discuss it. Many greetings juh -- Hostsharing eG – die Hosting-Genossenschaft Souveränität – Nachhaltigkeit – Exzellenz https://www.hostsharing.net

Am 2019-11-22 um 09:46 schrieb Mojca Miklavec :

On Fri, 22 Nov 2019 at 08:51, Jan U. Hasecke wrote:

...

I am very interested in running ConTeXt as a service, too. I am still nurturing the idea of a publishing cooperative for self publishers with a Markdown --> Pandoc --> ConTeXt workflow with a nice web frontend. I hope to make it to the next ConTeXt meeting to discuss it.

If you want to start from a simple markup language, at least go for asciidoc or restructured text. Markdown is a mess for anything but very very very trivial structure, and very very soon you basically end up with "basically ugly html with some embeded plain text every now and then".

There is some proof-of-concept test document which goes via the asciidoc --[asciidoctor]--> docbook (xml) --[context]--> pdf path (but it needs more work to be fully useful).

Wouldn’t it make sense to go (X)HTML->ConTeXt? Then you can use one of the online JS editors like CKeditor. Massi can tell more, I guess; i.e. he already told us a lot, I just can’t remember the details. For his MEO project he extended one of the editors to allow for additional markup. Greetlings, Hraban --- https://www.fiee.net http://wiki.contextgarden.net https://www.dreiviertelhaus.de GPG Key ID 1C9B22FD

Thank you for all the responses and the inspiration. I'll have to think about what is possible and what might be of use for others, but the initial idea to create a plugin looks actually quite feasible to me now, apart from the fact that I don't know PHP which is needed for OJS plugins, but that's another story... Best, Denis

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 can’t remember which JS editor I used >10 years ago for the editorial system of a city magazine, but I remember I only allowed a few tags (authors weren’t allowed to use font and color settings) and also run a HTML cleaner before saving. It was an effort until it worked, but not that much. Greetlings, Hraban --- https://www.fiee.net http://wiki.contextgarden.net https://www.dreiviertelhaus.de GPG Key ID 1C9B22FD

Am 2019-11-23 um 13:18 schrieb luigi scarso : another link: https://coko.foundation/ https://coko.foundation/product-suite/

or merely https://pubsweet.coko.foundation Thank you for the hint, sounds interesting and like the thing I always wanted to build… I didn’t read everything, but I didn’t find any hints how (if?) they produce PDFs or other output formats. Greetlings, Hraban

On 11/23/2019 1:18 PM, luigi scarso wrote:

On Sat, Nov 23, 2019 at 1:02 PM Henning Hraban Ramm mailto:texml@fiee.net> wrote:

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 can’t remember which JS editor I used >10 years ago for the editorial system of a city magazine, but I remember I only allowed a few tags (authors weren’t allowed to use font and color settings) and also run a HTML cleaner before saving. It was an effort until it worked, but not that much.

another link: https://coko.foundation/ https://coko.foundation/product-suite/

Sounde nice but then tne question is: which of these will stay for a long term (commitment, open etc). Always a bit of a ganmble. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

Am 2019-11-23 um 15:14 schrieb Mojca Miklavec :

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

Am 2019-11-23 um 16:50 schrieb Mojca Miklavec :

On Sat, 23 Nov 2019 at 16:40, Henning Hraban Ramm wrote:

...

...

Am 2019-11-23 um 15:14 schrieb Mojca Miklavec: 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.

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?

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

So where do we stand with "you are exaggerating, it's really simple", then? How many hours to configure it? ;)

I was thinking about text (articles, literature), you were thinking about complex material. The first is simple, the latter is, well, at least complex.

(ConTeXt has no problems doing all that, and asciidoc as potential input format supports all the required features as well;

But that’s structured input; I thought we were talking about HTML editors. HTML is only well structured (in a general sense, not XML) if you write it this way manually or if you severely limit the user of an editor.

if a nice translation layer is defined, one can get both awesome html out of the box as well as high quality PDF. I'm just saying that I find MCE somewhat useless. Whether or not that's exaggerating ... still waiting to be proven wrong.)

MCE is a known example, but probably not the best for every purpose. Also a matter of taste...

...

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.

Well ... both Word and Open/LibreOffice do a pretty decent job w.r.t math nowadays, MathJax is awesome, and I've also seen some awesome javascript apps allowing you to edit equations. So it's not impossible. Just not that straightforward …

Since I seldom need formulae, I got no experience with those. Last time I had to use Word’s formula editor it was horrible, but that was in 2005 or so, and Microsoft did their homework since. I guess it’s still easier to write TeX code than clicking formulae together.

I'm not saying that I really need a WYSIWYG editor. Anyone who's supposed to enter correct complex formulas should be able to learn some basic markup language (I guess).

I agree. Best, Hraban

Il 23/11/19 13:02, Henning Hraban Ramm ha scritto:

...

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.)

Indeed, an ongoing effort. Markup should be mostly semantic, leaving the most of styling to ConTeXt or CSS or whatever. But then you must consider the features and limitations of the tools you use. CKEditor lets you define rules to specify what can enter your sources; it's great, but it's essentially a HTML editor, not a semantic editor. In CKE, the HTML is *the* document, not a representation of it inside a browser. Prosemirror is the best editor i know, if you care about complete control of what goes into your sources. It's document agnostic, HTML is used only to represent the document in a browser. Your document could be JSON or markdown or whatever. Prosemirror is actually an editor kit, not an editor: - Tiptap editor combines Prosemirror with Vue.js - wax-prosemirror instead combines Prosemirror with React.js I'm developing on top of wax-prosemirror, which should be the next version of the editor inside Editoria by Coko Foundation (Luigi posted a couple of links in another reply of this thread). Jure Triglav of Coko Foundation wrote a good post on open source collaborative editors: https://juretriglav.si/open-source-collaborative-text-editors/

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.

Even though we started with a semantic tagging mindset, we always find alien tags or wrong combinations of allowed tags in our sources. It's not only pasting from Word or a web page, sometimes it's browsers' plugins or different behaviors among different browsers. And bugs of my code, of course. I feel it's hard to exaggerate in paying attention to that, there's always something unwanted sneaking in.

I can’t remember which JS editor I used >10 years ago for the editorial system of a city magazine, but I remember I only allowed a few tags (authors weren’t allowed to use font and color settings) and also run a HTML cleaner before saving. It was an effort until it worked, but not that much.

We have filters to clean up a source before editing, rules inside a CKE-based editor and filters to do other cleanups while saving. We have quite a good control over sources, yet it's not complete. A lot depends on the complexity of your documents: you start simple and do some assumptions; later you want to increase complexity, add new features that must combine with the legacy of every assumption you did in the past. More complex documents, more room for unwanted markup to enter them. I admire Pandoc's document model: it's simple enough, well specified, with generic tags (Div for blocks and Span for inlines) that carry information with classes and key-value data, RawInlines and RawBlocks to inject low level tagging for specific formats. Generics and Raw objects let you represent and convert many elements that are not built in. Massi

On 11/23/2019 4:39 PM, mf wrote:

The problems arise when you need to move data to and from the container. Docker lets you share a local filesystem path with the container, but that's not possible on a network (with the same performance of a local filesystem, i mean).

Just curious: what is the bottleneck there? When we run context as a 'service' we always do that on an nfs mount (even the tex tree). Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------