Re: RFC: Designing Logo of Pandoc

[BP Jonsson <bpjonsson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

Den 2016-12-16 kl. 22:01, skrev John MacFarlane:
> There are lots of people who post to the issue tracker
> things like:  why can't you support feature X in Source
> Format?  It renders in Target Format like so...
>
> They often don't realize that in order to do this, we'd have
> to make feature X representable in the AST, and that
> would mean handling it in every reader and every writer.
>
> I think that's the kind of thing Kolen is referring to.

Yes I realize that, but the remedy for that is a prominent note in 
the manual explaining the situation, not complicationg a logo.

Honestly I don't think those people give a farthing how and why
it doesn't work, once they realize that it doesn't work.
The tiny fraction who do care don't need to be reminded by a logo 
design and the many who don't care won't start to care because of 
a logo design.

Something along the lines of "Pandoc uses an internal 
representation of the processed document which is mostly limited 
to what can be represented in Pandoc's own Markdown variant.
This means that some features in other source formats aren't 
supported by Pandoc and can't be implemented without radical 
changes to the internal representation which are not likely to be 
implemented anytime soon. This does however not mean that new 
features which make sense in Pandoc's Markdown are out of the 
question. Such features have been added from time to time and that 
may well happen again in the future." in the manual and in 
CONTRIBUTING.md would probably be both needed and sufficient.

/bpj

>
> +++ BP Jonsson [Dec 16 16 16:39 ]:
>>   TL;DR: I see no reason to require that a logo reflects aspects
>> of the
>>   project beyond the basic public interface, and absolutely no
>> reason to
>>   make a logo design unnecessarily complex for such a reason,
>> because
>>   there shouldn't be any pressure on users to get involved
>> beyond the
>>   public interface, except as and when they feel the need
>> themselves.
>>   I've been thinking a bit more about this and I wonder what
>> kinds of
>>   misunderstandings of the model you are thinking of. The
>> closest thing I
>>   have seen on this list and on StackExchange has been users
>> getting
>>   bitten by this or that feature of LaTeX or RestructuredText
>> not being
>>   representable in the current AST format. I wouldn't call that
>>   misunderstanding of the model but rather ignorance of what
>> structural
>>   elements of supported markup formats *the current
>> implementation of the
>>   model* can or cannot represent. That's not even limitations of
>> the
>>   model but limitations of the current implementation which
>> could be
>>   removed[^1] in a future implementation. I would argue that if
>> they were
>>   removed most users would just say "phew, finally pandoc
>> supports my
>>   favorite markup feature" without caring about what changes in the
>>   implementation, let alone the model, have made it possible.
>> That is as
>>   it should be. Users should not be required, prodded or even
>> expected to
>>   understand the engineering behind an application, only the public
>>   interface. What sets open source apart is that users *may*
>> explore,
>>   understand and get involved in the engineering, even are
>> invited to do
>>   so, but there should be no pressure to do so. Even those who
>> do get
>>   involved usually only do so as and when they are able and
>> willing to
>>   enhance their own use of the product, or for their own
>> gratification,
>>   and that's entirely as it should be. Myself I'm still a total
>> Haskell
>>   illiterate, confining my contributions, and hence also my
>>   understanding, to filterland. I have gotten rather involved in
>> Jakob's
>>   Perl filter support project, but that's in the end also
>> helping myself
>>   to write filters in my preferred language. To be sure I have
>> written
>>   some filters in response to requests on this list, but
>> naturally that
>>   has been as and when I have had, or got, an interest in the
>>   functionality requested. Otherwise I have only more or less
>>   successfully requested John or others to add features I have
>> needed.
>>   That may change some day but there are hundreds if not
>> thousands of
>>   users out there who don't even get to the level where I am,
>> and that's
>>   entirely legitimate.
>>   [^1]: NB I'm saying "could", not "should", but I'm thinking
>> that even
>>   without extending the current set of AST elements some
>> unsupported
>>   input format constructs could optionally be turned into Div,
>> Span or
>>   link elements with certain attributes by the readers so that
>> they could
>>   be handled with filters or turned back into their original
>> constructs
>>   by the corresponding writers -- optionally, since those
>> attributes
>>   containers would clutter the markdown output. That's another
>> discussion
>>   however!
>>   /bpj
>>
>>   Den 16 dec 2016 00:55 skrev "BP Jonsson"
>> <[1]bpjonsson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>
>>     You may see the ∀ in the middle as representing the ∀ST
>> around which
>>     the conversion between different input and output formats
>> revolves!
>>     :-)
>>     /bpj
>>     Den 2016-12-15 kl. 01:40, skrev Kolen Cheung:
>>
>>     On Wednesday, December 14, 2016 at 8:45:41 AM UTC-8, BP wrote:
>>     To a normal user (I.e. you aren’t a Pandoc contributor or
>> filter
>>     author)
>>     the AST is an implementation detail which you don’t interact
>> with.
>>     The
>>     normal user experience is pandoc -f markdown -t html`, i.e. you
>>     input a
>>     document in one markup format and get (a file) in anotheir
>> markup
>>     format
>>     (possibly zipped together with sundry other files) as output,
>>     without any
>>     intermediate file or files. There is no point in creating a
>> false
>>     impression that there always must be an intermediate file.
>> In fact
>>     that may
>>     scare off potential normal users. To them the thing which sets
>>     pandoc apart
>>     from other light markup processors is that it supports
>> conversion
>>     back and
>>     forth between multiple markup formats, and the logo should
>> emphasize
>>     that.
>>     The logo needs to be intelligible and meaningful to the less
>> geeky
>>     users
>>     which hopefully are in majority.
>>     /bpj
>>     It certainly is another possible perspective. So let me
>> illustrate
>>     more on
>>     my perspective:
>>        1.
>>        There are countless examples of expectation from end-users
>>     (including
>>        me) that originated from the misunderstanding of what
>> pandoc is
>>     and what
>>        pandoc does. Rather than trying not to “scare off potential
>>     normal users”
>>        (which is unlikely to happen from a logo alone, since
>> they won’t
>>     understand
>>        the nuance in it at first sight), may be we should set the
>>     expectation
>>        right as early as possible, so that they won’t be
>> disappointed
>>     later on,
>>        and will not waste time to use pandoc for the wrong task.
>>        2.
>>        The logo having arrows pointing to a common element
>> representing
>>     AST
>>        will not make a real difference on first sight. But it
>> would be a
>>     great
>>        “entry point” to talk about the philosophy behind pandoc.
>> Having
>>     a 2nd
>>        layer of sophistication means intelligible and meaningful
>> to me.
>>     (i.e. at
>>        first sight you get something, but there’s a deeper story
>> behind
>>     it.)
>>        - To further illustrate on this point, at first glance,
>> pandoc
>>     seems
>>           very similar to some other tool, e.g. MultiMarkdown.
>> But as
>>     one pushes the
>>           tools further, they will realize pandoc is much deeper
>> than
>>     what it seems
>>           like at first glance. So, if the logo can have layers of
>>     meaning, it
>>           represents pandoc better.
>>     I don’t mean it has to be done this way. I mean if there’s
>> arrows,
>>     arrows
>>     pointing to a common element is more correct and deeper, and
>> doesn’t
>>     really
>>     scare off people (may actually attract the right people),
>> and is a
>>     path
>>     worth explore. But if no design makes this looks good and
>> natural,
>>     we need
>>     not to force it.
>>     ​
>>
>>     --
>>     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
>> [2]pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>>     To post to this group, send email to
>>     [3]pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>>     To view this discussion on the web visit
>>     [4]https://groups.google.com/d/msgid/pandoc-discuss/29dbdf52-29
>>     4b-b6a9-b598-ea742b5d4afb%40gmail.com.
>>     For more options, visit [5]https://groups.google.com/d/optout.
>>
>>   --
>>   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 [6]pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>>   To post to this group, send email to
>>   [7]pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>>   To view this discussion on the web visit
>>
>> [8]https://groups.google.com/d/msgid/pandoc-discuss/CAFC_yuRfJ_8rEtGqxJ
>>
>>   vnWudMKT%2Bpgm8Go_cqoQ9TMDcN%2BqnsBA%40mail.gmail.com.
>>   For more options, visit [9]https://groups.google.com/d/optout.
>>
>> References
>>
>>   1. mailto:bpjonsson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>>   2. mailto:pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
>>   3. mailto:pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
>>   4.
>> https://groups.google.com/d/msgid/pandoc-discuss/29dbdf52-294b-b6a9-b598-ea742b5d4afb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>>
>>   5. https://groups.google.com/d/optout
>>   6. mailto:pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
>>   7. mailto:pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
>>   8.
>> https://groups.google.com/d/msgid/pandoc-discuss/CAFC_yuRfJ_8rEtGqxJvnWudMKT+pgm8Go_cqoQ9TMDcN+qnsBA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org?utm_medium=email&utm_source=footer
>>
>>   9. https://groups.google.com/d/optout
>

-- 
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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/a854ab0e-2a1f-a80a-4dd6-f092cea6e0fb%40gmail.com.
For more options, visit https://groups.google.com/d/optout.