4 ms·

How would your approach differ from something like RMarkdown or similar? Still trying to nail down the differentiation.

strogonoff 6y ago
At first approach it seems to be substantially different from what RMarkdown is intended for, though maybe I am not seeing some outside-the-box ways of using it. What I would like is more oriented around creating documents according to particular layout specs. Documents (books, technical documentation) that can be created using InDesign, but this time programmatically[0]. As content should be authored using semantic markup (for accessible PDFs to be produced), and styling & layout capabilities should be flexible enough, I can see how HTML+CSS paradigm could be viable (and would allow reusing many useful parts from web stack, such as self-containing components). If going with CSS, the latest spec is close but does not yet seem to be there as far as proper print media layout capabilities. A viable path could be extending an existing engine (Chromium?) specifically where it renders for print media, enabling rendering to accessible tagged PDF, and likely even introducing new styling capabilities making the spec a superset of CSS. (This all under assumption that it is at all feasible to achieve proper accessible PDF output using browser’s print capabilities.) [0] I know about variables & data import in InDesign, that is still dependent on GUI so not quite applicable.
- awinder 6y ago
  I know nothing of InDesign so that's likely where my problem understanding came in :). At work, we have a lot of data-defined reports that will generate daily based on real-world conditions. These reports then go out to business users internally but they're nicely done because they'll occasionally get shared with external audiences. The way the team structured it, which I thought was fairly slick, is they built a bunch of RMarkdown reports that output to LaTex as an intermediary format. Then there's custom LaTex stuff in the pipeline that makes layouts & styling transferable and sharable between the reports. From LaTeX you can go to a number of outputs like html and pdf and it's (I'll probably catch flack for laypersons explanation) maybe a more print-oriented layout/typesetting system, versus html/css which came later. This felt maybe more relevant before than now :)

At first approach it seems to be substantially different from what RMarkdown is intended for, though maybe I am not seeing some outside-the-box ways of using it. What I would like is more oriented around creating documents according to particular layout specs. Documents (books, technical documentation) that can be created using InDesign, but this time programmatically[0]. As content should be authored using semantic markup (for accessible PDFs to be produced), and styling & layout capabilities should be flexible enough, I can see how HTML+CSS paradigm could be viable (and would allow reusing many useful parts from web stack, such as self-containing components). If going with CSS, the latest spec is close but does not yet seem to be there as far as proper print media layout capabilities. A viable path could be extending an existing engine (Chromium?) specifically where it renders for print media, enabling rendering to accessible tagged PDF, and likely even introducing new styling capabilities making the spec a superset of CSS. (This all under assumption that it is at all feasible to achieve proper accessible PDF output using browser’s print capabilities.) [0] I know about variables & data import in InDesign, that is still dependent on GUI so not quite applicable.

awinder 6y ago
I know nothing of InDesign so that's likely where my problem understanding came in :). At work, we have a lot of data-defined reports that will generate daily based on real-world conditions. These reports then go out to business users internally but they're nicely done because they'll occasionally get shared with external audiences. The way the team structured it, which I thought was fairly slick, is they built a bunch of RMarkdown reports that output to LaTex as an intermediary format. Then there's custom LaTex stuff in the pipeline that makes layouts & styling transferable and sharable between the reports. From LaTeX you can go to a number of outputs like html and pdf and it's (I'll probably catch flack for laypersons explanation) maybe a more print-oriented layout/typesetting system, versus html/css which came later. This felt maybe more relevant before than now :)