From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.text.pandoc/11855 Path: news.gmane.org!not-for-mail From: Shahbaz Youssefi Newsgroups: gmane.text.pandoc Subject: Re: Is it possible to extend pandoc table model to support colspans and rowspans? Date: Tue, 27 Jan 2015 17:26:20 +0100 Message-ID: References: <9a58c476-9917-4dfc-b4d5-ced95433e88c@googlegroups.com> <20150127161139.GF91984@localhost.hsd1.ca.comcast.net> Reply-To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e013d11520ee20e050da4b767 X-Trace: ger.gmane.org 1422375985 5984 80.91.229.3 (27 Jan 2015 16:26:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 Jan 2015 16:26:25 +0000 (UTC) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Original-X-From: pandoc-discuss+bncBCROTOMZXUKRBLHYT2TAKGQEVXKEEWY-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Tue Jan 27 17:26:25 2015 Return-path: Envelope-to: gtp-pandoc-discuss@m.gmane.org Original-Received: from mail-ee0-f63.google.com ([74.125.83.63]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YG8y5-00067N-V8 for gtp-pandoc-discuss@m.gmane.org; Tue, 27 Jan 2015 17:26:22 +0100 Original-Received: by mail-ee0-f63.google.com with SMTP id c13sf1328238eek.8 for ; Tue, 27 Jan 2015 08:26:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:sender:list-subscribe:list-unsubscribe; bh=QBonoRjftXCeYL3D9BIuZW5W0OugFAze+Va1tbTvNEI=; b=zAw9JT9Ib2zwIvSX+hJdGF7AGG6jZ1GIL7rMdRr8ORit5fgW2dQLxBUN3yJGli5QWT 9krFSZSZkfyZRdlHOJSLywjSPwp45IGEWcE5cFEGivyEbEOy9+lIVXmph84PJfBCiJr3 3se65J4gTD2V3+R9afJrd5HAjCvvV2b8hT12+A7Sz4mS1BXWEdouQmmSOQPKQzjvC4Xl h7mSQOzKZM+/P88b6dVGuBvfLrUcJHLKbO3+uMCSeNeNxtutk2YDyXMO4vgN1OQsOFLh Eo0mHueOF/wh+ClFqGGeFWrRtnFnxJyo0OgGks0MF/2iw5S8bsamodVOZZz0l8KWd5/f 4k7A== X-Received: by 10.152.42.173 with SMTP id p13mr31082lal.6.1422375981578; Tue, 27 Jan 2015 08:26:21 -0800 (PST) X-BeenThere: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Original-Received: by 10.152.27.137 with SMTP id t9ls55170lag.44.gmail; Tue, 27 Jan 2015 08:26:20 -0800 (PST) X-Received: by 10.152.219.136 with SMTP id po8mr393340lac.4.1422375980658; Tue, 27 Jan 2015 08:26:20 -0800 (PST) Original-Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com. [2a00:1450:4010:c03::22e]) by gmr-mx.google.com with ESMTPS id xl7si134827lbb.1.2015.01.27.08.26.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Jan 2015 08:26:20 -0800 (PST) Received-SPF: pass (google.com: domain of shabbyx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org designates 2a00:1450:4010:c03::22e as permitted sender) client-ip=2a00:1450:4010:c03::22e; Original-Received: by mail-la0-x22e.google.com with SMTP id s18so14251385lam.5 for ; Tue, 27 Jan 2015 08:26:20 -0800 (PST) X-Received: by 10.152.4.200 with SMTP id m8mr2872830lam.2.1422375980555; Tue, 27 Jan 2015 08:26:20 -0800 (PST) Original-Received: by 10.112.128.163 with HTTP; Tue, 27 Jan 2015 08:26:20 -0800 (PST) In-Reply-To: <20150127161139.GF91984-bi+AKbBUZKbivNSvqvJHCtPlBySK3R6THiGdP5j34PU@public.gmane.org> X-Original-Sender: shabbyX-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of shabbyx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org designates 2a00:1450:4010:c03::22e as permitted sender) smtp.mail=shabbyx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org; contact pandoc-discuss+owners-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org List-ID: X-Google-Group-Id: 1007024079513 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , Xref: news.gmane.org gmane.text.pandoc:11855 Archived-At: --089e013d11520ee20e050da4b767 Content-Type: text/plain; charset=UTF-8 Before I came to know pandoc and its table extensions, I had an idea for generic tables in markdown which would support row/colspan as well as column widths etc. I liked the simplicity of pandoc tables (mostly regarding typing them), so I never brought it up here. Anyway, here's how I had imagined the markdown tables: - Each horizontal table line is a line consisting of `-` - Each vertical table line is a line consisting of `|` - Each top or non-vertically-terminating cross-point is a `+` - Each vertically terminating cross-point is a `*` Here are a few examples: +----------+--------+ | very | simple | +----------*--------+ | table | *-------------------* +--------+-------------+ | a bit | more | | +-------------+ +--------+ complicated | | than | | +--------+-------------+ | the | other | *--------*-------------* +--------+------------+---------------+ | A | _more_ | | +--------* | `general` | | +------+ | | | | | +----+---------+ +--------+------+ | | form | | | | +----*---------*------+--------*------+ | | | *---------------------*---------------* +---------------------------+ | | | +--------+---------+ | | | table | within | | | +--------*---------+ | | | another table | | | *------------------* | | | *---------------------------* Inside the tables, you recursively have Markdown text, with all its features. So basically the parser for the table would keep the text inside each cell separately (with its own leading whitespaces) and recursively parse them as if they were standalone texts. Given the layout of the table, the code generator would know how to manage `colspan`, `rowspan` etc. Would it be hell parsing this? I had thought about it at the time and I believe not. The `+` and `*` marks are essential for keeping track of where `|` is expected on the next line, dividing cells. So the parser would generally go over the first line, remember the `+` positions, and go through each subsequent line and divide up the text in different blocks (unparsed). It would continue like this and add or remove blocks as it sees `-----`s, `+`s and `*`s. Once the table is completely read, as I already said. it recursively parses each cell as if it was a markdown text on its own. On Tue, Jan 27, 2015 at 5:11 PM, John MacFarlane wrote: > +++ zozlak [Jan 26 15 01:17 ]: > >> Most of formats supported by Pandoc supports table cells spanning across >> multiple columns and/or rows but unfortunately Pandoc table model does >> not. >> Is there any possibility to include support for that in Pandoc? >> >> For me the most demanding is to add support for any markdown input format >> (for example as another one optional markdown extension) and HTML/HTML5 >> and >> PDF output formats. >> > > Figuring out how to do row/colspans in Markdown is the hard part. > > -- > 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/20150127161139.GF91984%40localhost.hsd1.ca.comcast. > net. > > For more options, visit 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/CALeOzZ85qaZJnGsgRFN5ar6-3CpXTtpqma7qC_ojJAwoR2ptig%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. --089e013d11520ee20e050da4b767 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Before I came to know pandoc and its table exten= sions, I had an idea for generic tables in markdown which would support row= /colspan as well as column widths etc. I liked the simplicity of pandoc tab= les (mostly regarding typing them), so I never brought it up here.

<= /div>Anyway, here's how I had imagined the markdown tables:

- Ea= ch horizontal table line is a line consisting of `-`
- Each vertical tab= le line is a line consisting of `|`
- Each top or non-vertically-termina= ting cross-point is a `+`
- Each vertically terminating cross-point is a `*`

Here are a few ex= amples:

=C2=A0 +--= --------+--------+
=C2=A0 |=C2=A0=C2=A0 very=C2=A0=C2=A0 | simple |
=C2=A0 +----------*--------+
=C2=A0 |=C2=A0 =C2=A0=C2=A0 =C2=A0 table=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |
=C2=A0 *-------------------*

=C2=A0 +--------+-= ------------+
= =C2=A0 | a bit=C2=A0 |=C2=A0=C2=A0 more =C2=A0 =C2=A0=C2=A0 |
=C2=A0 |=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-------------+
=C2=A0 +--------+ complicated |
=C2=A0 | than=C2=A0=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |
=C2=A0 +--------+-------------+
=C2=A0 |=C2=A0 the=C2=A0=C2=A0 |=C2=A0=C2=A0 other=C2=A0= =C2=A0=C2=A0=C2=A0 |
=C2=A0 *--------*-------------*

=C2=A0 +--------+------------+= ---------------+
=C2=A0 |=C2=A0=C2= =A0 A =C2=A0=C2=A0 |=C2=A0=C2=A0 _more_ =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
= =C2=A0 +--------* =C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 `general` = =C2=A0 |
=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +------+= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |
=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |<= br>=C2=A0 +----+---------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--------+------+<= br>
=C2= =A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0 form =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |
=C2=A0 = +----*---------*------+--------*------+
=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0 *---------------------*------= ---------*

=C2=A0 +---------------------------+
=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |
=C2=A0 |=C2=A0=C2=A0 +--------+---------+=C2=A0=C2=A0= =C2=A0 |
=C2=A0 |=C2=A0=C2=A0 | table=C2=A0 | within=C2=A0 |=C2=A0 =C2=A0 |
=
=C2=A0 |=C2=A0=C2=A0 +--------*-= --------+=C2=A0=C2=A0=C2=A0 |
= =C2=A0 |=C2=A0=C2=A0 |=C2= =A0 another table =C2=A0 |=C2=A0=C2=A0=C2=A0 |
= = =C2=A0 |=C2=A0=C2=A0 *------------------* =C2=A0=C2=A0 |
=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |
=C2=A0 *---------------------------*
=
Inside the tables, you recursively have Markdown text, with all its features.=20 So basically the parser for the table would keep the text inside each=20 cell separately (with its own leading whitespaces) and recursively parse th= em as if they were standalone=20 texts. Given the layout of the table, the code generator would know how=20 to manage `colspan`, `rowspan` etc.

Would it be hell parsing this? I had thought about it at the time and= I believe not. The `+` and `*` marks are essential for keeping track of wh= ere `|` is expected on the next line, dividing cells. So the parser would g= enerally go over the first line, remember the `+` positions, and go through= each subsequent line and divide up the text in different blocks (unparsed)= . It would continue like this and add or remove blocks as it sees `-----`s,= `+`s and `*`s.=C2=A0 Once the table is completely read, as I already said.= it recursively parses each cell as if it was a markdown text on its own.


On Tue, Jan 27, 2015 at 5:11 PM, John MacFarlane <jgm@ber= keley.edu> wrote:
+++ zozl= ak [Jan 26 15 01:17 ]:
Most of formats supported by Pandoc supports table cells spanning across multiple columns and/or rows but unfortunately Pandoc table model does not.=
Is there any possibility to include support for that in Pandoc?

For me the most demanding is to add support for any markdown input format (for example as another one optional markdown extension) and HTML/HTML5 and=
PDF output formats.

 Figuring out how to do row/colspans in Markdown is the hard part.

--
You received this message because you are subscribed to the Google Groups &= quot;pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to pandoc-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to pandoc-discuss@googlegroups.com.<= br> To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-di= scuss/20150127161139.GF91984%40localhost.hsd1.ca.comcast.<= /u>net.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups &= quot;pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to pand= oc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To view this discussion on the web visit https://groups.= google.com/d/msgid/pandoc-discuss/CALeOzZ85qaZJnGsgRFN5ar6-3CpXTtpqma7qC_oj= JAwoR2ptig%40mail.gmail.com.
For more options, visit http= s://groups.google.com/d/optout.
--089e013d11520ee20e050da4b767--