* build customizability
@ 2020-05-01 13:57 brainchild
[not found] ` <43e8ce91-0738-4477-bcf5-e826219d9b1d-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
0 siblings, 1 reply; 14+ messages in thread
From: brainchild @ 2020-05-01 13:57 UTC (permalink / raw)
To: pandoc-discuss
[-- Attachment #1.1: Type: text/plain, Size: 855 bytes --]
If someone wished to ship a functional executable of Pandoc in the
distribution of a larger application, what possibility, if any, currently
exists for building such an executable that only provides selected features
of the full application but is significantly smaller in distribution
footprint? In other words, what possibility is available, separate from any
generic compiler settings, to customize a build for reduced executable size?
--
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/43e8ce91-0738-4477-bcf5-e826219d9b1d%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 1191 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: build customizability
[not found] ` <43e8ce91-0738-4477-bcf5-e826219d9b1d-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
@ 2020-05-01 15:51 ` John MacFarlane
[not found] ` <m2wo5vy7pz.fsf-pgq/RBwaQ+zq8tPRBa0AtqxOck334EZe@public.gmane.org>
2020-05-04 6:45 ` brainchild
2020-05-04 8:36 ` build customizability brainchild
2 siblings, 1 reply; 14+ messages in thread
From: John MacFarlane @ 2020-05-01 15:51 UTC (permalink / raw)
To: brainchild, pandoc-discuss
If you want just some of pandoc's features you'd have to do
surgery on the source code. Not recommended unless you know
your way around with Haskell. Of course the GPL permits
this kind of alteration, and distribution of the result,
provided the terms of the license are followed.
brainchild <ericlevy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> If someone wished to ship a functional executable of Pandoc in the
> distribution of a larger application, what possibility, if any, currently
> exists for building such an executable that only provides selected features
> of the full application but is significantly smaller in distribution
> footprint? In other words, what possibility is available, separate from any
> generic compiler settings, to customize a build for reduced executable size?
>
> --
> You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/43e8ce91-0738-4477-bcf5-e826219d9b1d%40googlegroups.com.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: build customizability
[not found] ` <m2wo5vy7pz.fsf-pgq/RBwaQ+zq8tPRBa0AtqxOck334EZe@public.gmane.org>
@ 2020-05-03 8:05 ` brainchild
[not found] ` <a9b39338-0830-45dc-bf30-59d8de61278b-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
0 siblings, 1 reply; 14+ messages in thread
From: brainchild @ 2020-05-03 8:05 UTC (permalink / raw)
To: pandoc-discuss
[-- Attachment #1.1: Type: text/plain, Size: 2204 bytes --]
I understand the answer.
The reason that I ask is that many user applications, such as editors and
other writing tools, are using Pandoc for writing printable or
distribution-ready output documents. Some simply invoke the command through
the system, yet others are including a copy of Pandoc in their
distribution. The latter approach circumvents the uncertainty of dependence
on a system installation, but at the cost of bloating distribution size.
And yet, of the many capabilities of Pandoc, it is unlikely more than a
select few are needed by any particular application of the above kind.
This observation leads me to wonder whether it is possible, at least in
principle, to achieve a substantially smaller executable size that offers a
specific selection of the full application's capabilities.
I understand that the current design would not make such a possibility
immediately feasible.
Still, I think the question is useful to consider.
Because of library dependencies, and the question of which libraries may be
unnecessary in specific cases, it very difficult for me, at the moment, to
address quantitatively how much smaller the footprint might be for some
particular case, if internal and external and components could be excluded
that are not required by a given set of needs.
I do notice that the readers and writers collectively consume about 80% of
the core application source code.
On Friday, May 1, 2020 at 11:51:20 AM UTC-4, John MacFarlane wrote:
>
>
> If you want just some of pandoc's features you'd have to do
> surgery on the source code. Not recommended unless you know
> your way around with Haskell. Of course the GPL permits
> this kind of alteration, and distribution of the result,
> provided the terms of the license are followed.
>
--
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/a9b39338-0830-45dc-bf30-59d8de61278b%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 3013 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: build customizability
[not found] ` <a9b39338-0830-45dc-bf30-59d8de61278b-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
@ 2020-05-03 12:39 ` Albert Krewinkel
[not found] ` <87wo5tgpkn.fsf-9EawChwDxG8hFhg+JK9F0w@public.gmane.org>
0 siblings, 1 reply; 14+ messages in thread
From: Albert Krewinkel @ 2020-05-03 12:39 UTC (permalink / raw)
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw
brainchild writes:
> This observation leads me to wonder whether it is possible, at least in
> principle, to achieve a substantially smaller executable size that offers a
> specific selection of the full application's capabilities.
I had a look into this some time ago. My conclusion was: while it is
possible to arrive at a smaller executable by manually disabling all
unwanted code, it is not worth the effort.
The question usually arises with the idea of using pandoc for Markdown
parsing, outputting various other formats. Many large parsers, like
those for LaTeX and HTML, are dependencies of the Markdown reader, so
they cannot be removed. The most commonly used writers are also some of
the most complex, so there is not that much to gain there either.
I seem to remember that, even after removing a significant amount of
functionality, I still achieved only a meager 20% reduction in binary
size. More aggressive pruning should be able to squeeze out some more
percentage points, but the binary will never really be "small".
--
Albert Krewinkel
GPG: 8eed e3e2 e8c5 6f18 81fe e836 388d c0b2 1f63 1124
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: build customizability
[not found] ` <87wo5tgpkn.fsf-9EawChwDxG8hFhg+JK9F0w@public.gmane.org>
@ 2020-05-03 12:55 ` brainchild
[not found] ` <459f63cf-31b3-48a4-adfe-21d5f23f9d22-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
0 siblings, 1 reply; 14+ messages in thread
From: brainchild @ 2020-05-03 12:55 UTC (permalink / raw)
To: pandoc-discuss
[-- Attachment #1.1: Type: text/plain, Size: 1348 bytes --]
Albert,
The truth may be as you say, but my intuitive sense of the number of
separate readers, writers, and dependencies leaves me to feel that some
suitable amount of engineering might produce results more optimal than the
ones you suggest. I have not done any tests, of course, myself.
A few questions on your response appear below.
parsing, outputting various other formats. Many large parsers, like
>
those for LaTeX and HTML, are dependencies of the Markdown reader, so
This observations strikes me as quite peculiar. Would you elaborate the
reasons for the dependencies?
> I seem to remember that, even after removing a significant amount of
> functionality, I still achieved only a meager 20% reduction in binary
>
Did your tests include the comprehensive elimination of unneeded library
dependencies? Doing so correctly might be nontrivial as it requires having
an accurate graph for dependency resolution.
--
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/459f63cf-31b3-48a4-adfe-21d5f23f9d22%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 2214 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: build customizability
[not found] ` <459f63cf-31b3-48a4-adfe-21d5f23f9d22-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
@ 2020-05-03 13:39 ` Ivan Lazar Miljenovic
[not found] ` <CA+u6gbwbuU9QhDFygzHh259Pa99qCTNBAq6-Jym6z24hhCF=PQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-05-03 15:07 ` Albert Krewinkel
1 sibling, 1 reply; 14+ messages in thread
From: Ivan Lazar Miljenovic @ 2020-05-03 13:39 UTC (permalink / raw)
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw
[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]
On Sun, 3 May 2020 at 20:55, brainchild <ericlevy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> parsing, outputting various other formats. Many large parsers, like
>>
> those for LaTeX and HTML, are dependencies of the Markdown reader, so
>
>
> This observations strikes me as quite peculiar. Would you elaborate the
> reasons for the dependencies?
>
Because the Markdown parser can parse HTML and LaTeX fragments in Markdown
documents.
Another factor to take into account in the binary size is the GHC Run Time
System, etc. This link is a bit dated but might give you some ideas:
https://stackoverflow.com/questions/6115459/small-haskell-program-compiled-with-ghc-into-huge-binary
--
Ivan Lazar Miljenovic
Ivan.Miljenovic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
http://IvanMiljenovic.wordpress.com
--
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/CA%2Bu6gbwbuU9QhDFygzHh259Pa99qCTNBAq6-Jym6z24hhCF%3DPQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 2524 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: build customizability
[not found] ` <CA+u6gbwbuU9QhDFygzHh259Pa99qCTNBAq6-Jym6z24hhCF=PQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2020-05-03 14:05 ` BPJ
0 siblings, 0 replies; 14+ messages in thread
From: BPJ @ 2020-05-03 14:05 UTC (permalink / raw)
To: pandoc-discuss
[-- Attachment #1: Type: text/plain, Size: 2643 bytes --]
Also binary size as opposed to memory usage and CPU usage is relatively
unimportant. I still remember when you had your system on one 3.5" disk and
your program *and* files on another. Now that was size restriction! I felt
like I had unlimited storage when I got an 80 MB HDD! If you have
experienced that it is hard to get worked up about saving a few tenths of
MBs in a binary which can be compressed to less than 25 MB in an age where
a somewhat dated phone has more than 60 GB for storage only. I'd be
interested to know where you are under that kind of size strictures in the
year 2020!
--
Better --help|less than helpless
Den sön 3 maj 2020 15:40Ivan Lazar Miljenovic <ivan.miljenovic@gmail.com>
skrev:
> On Sun, 3 May 2020 at 20:55, brainchild <ericlevy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>>
>> parsing, outputting various other formats. Many large parsers, like
>>>
>> those for LaTeX and HTML, are dependencies of the Markdown reader, so
>>
>>
>> This observations strikes me as quite peculiar. Would you elaborate the
>> reasons for the dependencies?
>>
>
> Because the Markdown parser can parse HTML and LaTeX fragments in Markdown
> documents.
>
> Another factor to take into account in the binary size is the GHC Run Time
> System, etc. This link is a bit dated but might give you some ideas:
> https://stackoverflow.com/questions/6115459/small-haskell-program-compiled-with-ghc-into-huge-binary
>
> --
> Ivan Lazar Miljenovic
> Ivan.Miljenovic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> http://IvanMiljenovic.wordpress.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "pandoc-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pandoc-discuss/CA%2Bu6gbwbuU9QhDFygzHh259Pa99qCTNBAq6-Jym6z24hhCF%3DPQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/pandoc-discuss/CA%2Bu6gbwbuU9QhDFygzHh259Pa99qCTNBAq6-Jym6z24hhCF%3DPQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/CADAJKhDW7y4JF3pDCMD4_6RoU36BwETeuPThmzKm%2BSG76rNVZw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 4593 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: build customizability
[not found] ` <459f63cf-31b3-48a4-adfe-21d5f23f9d22-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2020-05-03 13:39 ` Ivan Lazar Miljenovic
@ 2020-05-03 15:07 ` Albert Krewinkel
1 sibling, 0 replies; 14+ messages in thread
From: Albert Krewinkel @ 2020-05-03 15:07 UTC (permalink / raw)
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw
brainchild writes:
>> Many large parsers, like those for LaTeX and HTML, are dependencies
>> of the Markdown reader
>
> This observations strikes me as quite peculiar. Would you elaborate the
> reasons for the dependencies?
HTML can always be included in Markdown, and extensions like
`markdown_in_html_blocks` make it necessary to parse it.
IIRC, LaTeX is required for math support as well as the `+raw_tex`
extension. Removing those would mean rewriting large parts of the
parser.
>> I seem to remember that, even after removing a significant amount of
>> functionality, I still achieved only a meager 20% reduction in binary
>
> Did your tests include the comprehensive elimination of unneeded library
> dependencies? Doing so correctly might be nontrivial as it requires having
> an accurate graph for dependency resolution.
No, mostly for the reason you mention, but also because the number of
packages made redundant in my experiment were countable on one hand.
That's less than 10% of total dependencies.
--
Albert Krewinkel
GPG: 8eed e3e2 e8c5 6f18 81fe e836 388d c0b2 1f63 1124
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: build customizability
[not found] ` <43e8ce91-0738-4477-bcf5-e826219d9b1d-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2020-05-01 15:51 ` John MacFarlane
@ 2020-05-04 6:45 ` brainchild
[not found] ` <f9fd9cfe-e03f-45d3-bcb5-07267c28e565-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2020-05-04 8:36 ` build customizability brainchild
2 siblings, 1 reply; 14+ messages in thread
From: brainchild @ 2020-05-04 6:45 UTC (permalink / raw)
To: pandoc-discuss
[-- Attachment #1.1: Type: text/plain, Size: 3131 bytes --]
Thank you for the recent comments. Let me respond to all in one message, as
they overlap in scope.
I address a few issues, in sequence, as follows:
1. *Markdown reader dependencies: *I now understand the conflict. In
many potential deployment scenarios, for example applications that employ
Markdown source, the embedding of snippets in some target language is
unlikely to be needed, except perhaps as narrowly allowed for equations.
Thus, if this functionality were entirely enclosed in extensions, and if
those extensions could be disabled in the build, then in principle it may
be possible to realize the benefit of removing the dependencies on the
parsers. I understand that it would require restructuring the code.
2. *Evaluating size of library dependencies: *If, as Albert says, only a
handful of packages may be eliminated from the build, even in the case that
only a few readers or writers were needed, and if the size of these
packages is not vastly greater than the size of others, then clearly the
material benefit of eliminating certain readers and writers from the build
is very limited. However, I make a few notes:
1. Is the reason that most dependencies would remain even after
removing most of the readers and writers that these dependencies are needed
separately by all the readers and writers, or rather that they are needed
by the core application? In the latter case, perhaps some of the core
functionality not needed in basic uses, again at least in principle, can be
separated.
2. My earlier question directed mostly at the difficulty of
determining confidently the complete set of dependencies to remove, without
invoking a formal solution such as graph traversal, compared to the
possibility of missing a set in an informal assessment.
3. *Footprint of Runtime System:* No, I was not specifically aware of
the size of the Runtime System. I am having difficulty finding a clear
indication of how much size it adds to the final executable size, but
estimates that seem to recur are in the 10-15 megabyte range. If these
estimates are accurate, then it would be impossible to achieve vastly
smaller sizes, obviously, but this information alone is not sufficient to
conclude the impossibility of achieving significant savings through methods
already discussed. Also, I am seeing some hints that a GHC backend for LLVM
is available that makes possible much more optimal build results.
Unfortunately, I have not found any quantitative assessment of these
savings, nor can I find any active project maintaining this interface.
--
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/f9fd9cfe-e03f-45d3-bcb5-07267c28e565%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 3406 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: build customizability
[not found] ` <43e8ce91-0738-4477-bcf5-e826219d9b1d-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2020-05-01 15:51 ` John MacFarlane
2020-05-04 6:45 ` brainchild
@ 2020-05-04 8:36 ` brainchild
2 siblings, 0 replies; 14+ messages in thread
From: brainchild @ 2020-05-04 8:36 UTC (permalink / raw)
To: pandoc-discuss
[-- Attachment #1.1: Type: text/plain, Size: 1110 bytes --]
By the way, using a *hello world* example, I obtained the following results:
$ echo 'main = putStrLn "Hello, world!"' > hello.hs
$ ghc -o hello hello.hs
[1 of 1] Compiling Main ( hello.hs, hello.o )
Linking hello ...
$ ./hello
Hello, world!
$ ls -sh ./hello
1008K ./hello
Perhaps GHC is using only a subset of the RTS, due to the limited scope of
the program.
(The build target does appear to have a few dependencies, but I believe all
are independent of GHC: libgmp.so.10, libm.so.6, librt.so.1, libdl.so.2,
libffi.so.6, libpthread.so.0, libc.so.6).
Someone with more experience than I on the topic might comment on what, if
any, significance to associate with this result.
--
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/4afcbd69-3e64-4edd-adae-5782c59ed2f6%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 4893 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: build customizability
[not found] ` <f9fd9cfe-e03f-45d3-bcb5-07267c28e565-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
@ 2020-05-04 14:47 ` Daniel Staal
[not found] ` <75f238b6-2ae0-2e73-66c9-54245b7cd655-Jdbf3xiKgS8@public.gmane.org>
0 siblings, 1 reply; 14+ messages in thread
From: Daniel Staal @ 2020-05-04 14:47 UTC (permalink / raw)
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw
On 5/4/20 2:45 AM, brainchild wrote:
> *Markdown reader dependencies: *I now understand the conflict. In many
> potential deployment scenarios, for example applications that employ
> Markdown source, the embedding of snippets in some target language is
> unlikely to be needed, except perhaps as narrowly allowed for equations.
> Thus, if this functionality were entirely enclosed in extensions, and if
> those extensions could be disabled in the build, then in principle it
> may be possible to realize the benefit of removing the dependencies on
> the parsers. I understand that it would require restructuring the code.
Just replying to this - in this case, you're getting far removed from
Pandoc's processing, to the point where the input file for Pandoc is no
longer compatible with your system. What - at this point - is the
benefit for using the Pandoc codebase? If all you want is to parse
Markdown or Latex or some other input format, there's lots of
specialized parsers out there.
And further than that - what is the benefit to *Pandoc* of you using the
Pandoc code base? Since this would require a large restructure of the
core code, what makes that restructure worthwhile to the Pandoc project?
Again, you're getting well off of Pandoc's goals and aim - and there
are other products that do aim for that use.
Daniel T. Staal
--
---------------------------------------------------------------
This email copyright the author. Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes. This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: build customizability
[not found] ` <75f238b6-2ae0-2e73-66c9-54245b7cd655-Jdbf3xiKgS8@public.gmane.org>
@ 2020-05-05 2:11 ` brainchild
2020-05-05 8:39 ` Colored text R. Wils
1 sibling, 0 replies; 14+ messages in thread
From: brainchild @ 2020-05-05 2:11 UTC (permalink / raw)
To: pandoc-discuss
[-- Attachment #1.1: Type: text/plain, Size: 1834 bytes --]
> Just replying to this - in this case, you're getting far removed from
> Pandoc's processing, to the point where the input file for Pandoc is no
> longer compatible with your system. What - at this point - is the
> benefit for using the Pandoc codebase? If all you want is to parse
> Markdown or Latex or some other input format, there's lots of
> specialized parsers out there.
>
I believe the idea I am expressing is very different from the effect you
describe.
> And further than that - what is the benefit to *Pandoc* of you using the
> Pandoc code base? Since this would require a large restructure of the
> core code, what makes that restructure worthwhile to the Pandoc project?
> Again, you're getting well off of Pandoc's goals and aim - and there
> are other products that do aim for that use.
>
I'm not sure what you're asking. Pandoc itself can experience no benefits,
only its users and contributors, who participate in discussions such as
this one. The amount of restructuring required, however much it is
determined to be, as for any proposed enhancement, indeed might be a
prohibitive factor. At the moment, a discussion is occurring such that the
various difficulties may be discussed openly.
Note further my earlier comments, which make note of a group already using
Pandoc.
What specific project goals do you feel the proposed idea might undermine
or challenge?
--
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/a6771fd7-3253-43bc-82b3-caf659052052%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 2585 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Colored text
[not found] ` <75f238b6-2ae0-2e73-66c9-54245b7cd655-Jdbf3xiKgS8@public.gmane.org>
2020-05-05 2:11 ` brainchild
@ 2020-05-05 8:39 ` R. Wils
[not found] ` <CAJPsUMeBTr2BcSL8V8mQuh=50LDx+z8+547MUcMzZYqahF9CAQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
1 sibling, 1 reply; 14+ messages in thread
From: R. Wils @ 2020-05-05 8:39 UTC (permalink / raw)
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw
[-- Attachment #1: Type: text/plain, Size: 144 bytes --]
Does anyone know how to color text in a PDF (converting from a pandoc.
markdown text file)?
I tried to use a span and div tag without success.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Colored text
[not found] ` <CAJPsUMeBTr2BcSL8V8mQuh=50LDx+z8+547MUcMzZYqahF9CAQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2020-05-05 8:42 ` brainchild
0 siblings, 0 replies; 14+ messages in thread
From: brainchild @ 2020-05-05 8:42 UTC (permalink / raw)
To: pandoc-discuss
[-- Attachment #1.1: Type: text/plain, Size: 685 bytes --]
Perhaps you would present this question in a new topic?
On Tuesday, May 5, 2020 at 4:39:31 AM UTC-4, R. Wils wrote:
>
> Does anyone know how to color text in a PDF (converting from a pandoc.
> markdown text file)?
>
> I tried to use a span and div tag without success.
>
--
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/0b0ff08e-a73f-4893-86fe-cf23dfd2ad82%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 1204 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-05-05 8:42 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-01 13:57 build customizability brainchild
[not found] ` <43e8ce91-0738-4477-bcf5-e826219d9b1d-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2020-05-01 15:51 ` John MacFarlane
[not found] ` <m2wo5vy7pz.fsf-pgq/RBwaQ+zq8tPRBa0AtqxOck334EZe@public.gmane.org>
2020-05-03 8:05 ` brainchild
[not found] ` <a9b39338-0830-45dc-bf30-59d8de61278b-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2020-05-03 12:39 ` Albert Krewinkel
[not found] ` <87wo5tgpkn.fsf-9EawChwDxG8hFhg+JK9F0w@public.gmane.org>
2020-05-03 12:55 ` brainchild
[not found] ` <459f63cf-31b3-48a4-adfe-21d5f23f9d22-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2020-05-03 13:39 ` Ivan Lazar Miljenovic
[not found] ` <CA+u6gbwbuU9QhDFygzHh259Pa99qCTNBAq6-Jym6z24hhCF=PQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-05-03 14:05 ` BPJ
2020-05-03 15:07 ` Albert Krewinkel
2020-05-04 6:45 ` brainchild
[not found] ` <f9fd9cfe-e03f-45d3-bcb5-07267c28e565-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2020-05-04 14:47 ` Daniel Staal
[not found] ` <75f238b6-2ae0-2e73-66c9-54245b7cd655-Jdbf3xiKgS8@public.gmane.org>
2020-05-05 2:11 ` brainchild
2020-05-05 8:39 ` Colored text R. Wils
[not found] ` <CAJPsUMeBTr2BcSL8V8mQuh=50LDx+z8+547MUcMzZYqahF9CAQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-05-05 8:42 ` brainchild
2020-05-04 8:36 ` build customizability brainchild
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).