latest beta, problem with natural tables and alignment character
Hi, I was testing the latest beta (2014.06.15) and noticed I am getting incorrect output using natural tables with alignment characters. I produced a small example that demonstrates the problem, and attached output created with the version I'm testing (bad.pdf) and my prior version (good.pdf, ConTeXt 2013.06.10). You can see in the bad file that ConTeXt doesn't properly align on the "-" and it introduces spurious spaces. Best regards, Brian
On 6/16/2014 11:51 PM, Brian Landy wrote:
Hi, I was testing the latest beta (2014.06.15) and noticed I am getting incorrect output using natural tables with alignment characters. I produced a small example that demonstrates the problem, and attached output created with the version I'm testing (bad.pdf) and my prior version (good.pdf, ConTeXt 2013.06.10). You can see in the bad file that ConTeXt doesn't properly align on the "-" and it introduces spurious spaces.
i'll check it ... btw, you don't need all these %'s after a multi-char \cs ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
so instead of \bTD[]{Bond}\eTD% use this: \bTD Bond \eTD ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Almost all of the tables I generate via code, not by hand, so I found it more convenient to include a trailing % because I occasionally did run across an instance where it mattered, and wasn't (and am not) sufficiently skilled at TeX/ConTeXt to know how to predict those occurrences.
It's somewhat similar for always wrapping the contents in {}, I thought I had run into some cases in the past where it was necessary, so just include them always rather than manually add them with the content when they are required. Are there negative consequences (performance, memory usage, ...) to writing it as I did? Or is the difference just cosmetic?
Best regards,
Brian
On Jun 16, 2014, at 6:57 PM, Hans Hagen
so instead of
\bTD[]{Bond}\eTD%
use this:
\bTD Bond \eTD
----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl ----------------------------------------------------------------- ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
On 6/17/2014 5:49 AM, Brian Landy wrote:
Almost all of the tables I generate via code, not by hand, so I found it more convenient to include a trailing % because I occasionally did run across an instance where it mattered, and wasn't (and am not) sufficiently skilled at TeX/ConTeXt to know how to predict those occurrences.
It's somewhat similar for always wrapping the contents in {}, I thought I had run into some cases in the past where it was necessary, so just include them always rather than manually add them with the content when they are required. Are there negative consequences (performance, memory usage, ...) to writing it as I did? Or is the difference just cosmetic?
the empty [] always has a performance hit, for {} it depends what extra restores have to happen
Best regards, Brian
On Jun 16, 2014, at 6:57 PM, Hans Hagen
wrote: so instead of
\bTD[]{Bond}\eTD%
use this:
\bTD Bond \eTD
----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl ----------------------------------------------------------------- ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
-- ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 6/16/2014 11:51 PM, Brian Landy wrote:
Hi, I was testing the latest beta (2014.06.15) and noticed I am getting incorrect output using natural tables with alignment characters. I produced a small example that demonstrates the problem, and attached output created with the version I'm testing (bad.pdf) and my prior version (good.pdf, ConTeXt 2013.06.10). You can see in the bad file that ConTeXt doesn't properly align on the "-" and it introduces spurious spaces.
i assume you haven't updated in a while as this is not something last beta specific the alignment code has been redone some time ago (the general mechanism is more clever now) and it was mostly made for aligning numbers (not so much for your case as - is seen as minus) anyhow, i made it work a bit better with tables (extra pass needed) \starttext \enabletrackers[typesetters.characteralign] \bgroup \setupTABLE[column][1][aligncharacter=yes,alignmentcharacter={,}] \bTABLE \bTR \bTD 1,2 \eTD \bTD 1,2 \eTD \bTD xxx \eTD \eTR \bTR \bTD - 1,2 \eTD \bTD -1,2 \eTD \bTD xxx \eTD \eTR \bTR \bTD -1,2 \eTD \bTD -1,2 \eTD \bTD xxx \eTD \eTR \bTR \bTD 11,2 \eTD \bTD 11,2 \eTD \bTD xxx \eTD \eTR \bTR \bTD 11,224 \eTD \bTD 11,22 \eTD \bTD xxx \eTD \eTR \eTABLE \egroup \bgroup \setupTABLE[column][1][aligncharacter=yes,alignmentcharacter={-}] \setupTABLE[column][2][aligncharacter=yes,alignmentcharacter={\endash}] \bTABLE \bTR \bTD 1-2 \eTD \bTD 1\endash2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 1-2 \eTD \bTD 1\endash2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 1-2 \eTD \bTD 1\endash2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 11-2 \eTD \bTD 11\endash2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 11-22 + \eTD \bTD 11\endash22 + \eTD\bTD xxx \eTD \eTR \eTABLE \egroup \stoptext the next beta can handle this Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Jun 17, 2014, at 11:18 AM, Hans Hagen
On 6/16/2014 11:51 PM, Brian Landy wrote:
Hi, I was testing the latest beta (2014.06.15) and noticed I am getting incorrect output using natural tables with alignment characters. I produced a small example that demonstrates the problem, and attached output created with the version I'm testing (bad.pdf) and my prior version (good.pdf, ConTeXt 2013.06.10). You can see in the bad file that ConTeXt doesn't properly align on the "-" and it introduces spurious spaces.
i assume you haven't updated in a while as this is not something last beta specific
the alignment code has been redone some time ago (the general mechanism is more clever now) and it was mostly made for aligning numbers (not so much for your case as - is seen as minus)
Yes, I hadn't updated in about a year. I am running into a luatex exception in the version I'm using and want to see if the problem goes away if I update. FYI, I was seeing similar problems aligning on a period, but I'll test it out in the next beta. I do have a few cases where I've used alignmentcharacter={\thinspace} to work around some trickier problems where I needed to mix numbers and text and align in a specific way, do you think that will continue to work? Actually at one point \zerowidthspace worked for this, but then stopped (I don't recall exactly when); my workaround was to add \thinspace\negthinspace to the text where I wanted the alignment to occur. In fact, I possibly should have done this in my example, to avoid confusion of which "-" to align on in a number like "-0-25+." As an aside, these are actually numbers—they are bond prices quoted in 32nds where the "+" is a 64th, so -0-25+ == -0.796875 and 97-08+ == 97.265625. There are other conventions used, sometimes a colon instead of a dash (-0:25+), and sometimes numbers like -0-25:4, where the number following the colon is 8ths of a 32nd. So it has always been extremely useful to have the flexibility to align on a variety of characters, as well as not having problems caused by other text mixed in with the numbers—currency symbols, % signs, etc. Best regards, Brian
On Tue, 17 Jun 2014, Hans Hagen wrote:
anyhow, i made it work a bit better with tables (extra pass needed)
\starttext
\enabletrackers[typesetters.characteralign]
\bgroup \setupTABLE[column][1][aligncharacter=yes,alignmentcharacter={,}] \bTABLE \bTR \bTD 1,2 \eTD \bTD 1,2 \eTD \bTD xxx \eTD \eTR \bTR \bTD - 1,2 \eTD \bTD -1,2 \eTD \bTD xxx \eTD \eTR \bTR \bTD -1,2 \eTD \bTD -1,2 \eTD \bTD xxx \eTD \eTR \bTR \bTD 11,2 \eTD \bTD 11,2 \eTD \bTD xxx \eTD \eTR \bTR \bTD 11,224 \eTD \bTD 11,22 \eTD \bTD xxx \eTD \eTR \eTABLE \egroup
\bgroup \setupTABLE[column][1][aligncharacter=yes,alignmentcharacter={-}] \setupTABLE[column][2][aligncharacter=yes,alignmentcharacter={\endash}] \bTABLE \bTR \bTD 1-2 \eTD \bTD 1\endash2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 1-2 \eTD \bTD 1\endash2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 1-2 \eTD \bTD 1\endash2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 11-2 \eTD \bTD 11\endash2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 11-22 + \eTD \bTD 11\endash22 + \eTD\bTD xxx \eTD \eTR \eTABLE \egroup
\stoptext
the next beta can handle this
When you say "next beta" do you mean a subsequent minimals release (i.e., this fix should be the 2014.06.22 release)? Or do you mean a new beta that you announce more formally on the list? I'm not sure what I should look for before I test again, so I don't end up testing a version without the fix. Brian
On 6/25/2014 11:26 PM, Brian R. Landy wrote:
On Tue, 17 Jun 2014, Hans Hagen wrote:
anyhow, i made it work a bit better with tables (extra pass needed)
\starttext
\enabletrackers[typesetters.characteralign]
\bgroup \setupTABLE[column][1][aligncharacter=yes,alignmentcharacter={,}] \bTABLE \bTR \bTD 1,2 \eTD \bTD 1,2 \eTD \bTD xxx \eTD \eTR \bTR \bTD - 1,2 \eTD \bTD -1,2 \eTD \bTD xxx \eTD \eTR \bTR \bTD -1,2 \eTD \bTD -1,2 \eTD \bTD xxx \eTD \eTR \bTR \bTD 11,2 \eTD \bTD 11,2 \eTD \bTD xxx \eTD \eTR \bTR \bTD 11,224 \eTD \bTD 11,22 \eTD \bTD xxx \eTD \eTR \eTABLE \egroup
\bgroup \setupTABLE[column][1][aligncharacter=yes,alignmentcharacter={-}] \setupTABLE[column][2][aligncharacter=yes,alignmentcharacter={\endash}] \bTABLE \bTR \bTD 1-2 \eTD \bTD 1\endash2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 1-2 \eTD \bTD 1\endash2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 1-2 \eTD \bTD 1\endash2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 11-2 \eTD \bTD 11\endash2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 11-22 + \eTD \bTD 11\endash22 + \eTD\bTD xxx \eTD \eTR \eTABLE \egroup
\stoptext
the next beta can handle this
When you say "next beta" do you mean a subsequent minimals release (i.e., this fix should be the 2014.06.22 release)? Or do you mean a new beta that you announce more formally on the list? I'm not sure what I should look for before I test again, so I don't end up testing a version without the fix.
netx beta == next upload == already done ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Jun 25, 2014, at 6:53 PM, Hans Hagen
On 6/25/2014 11:26 PM, Brian R. Landy wrote:
When you say "next beta" do you mean a subsequent minimals release (i.e., this fix should be the 2014.06.22 release)? Or do you mean a new beta that you announce more formally on the list? I'm not sure what I should look for before I test again, so I don't end up testing a version without the fix.
netx beta == next upload == already done
Great, thanks. I wanted to make sure before mentioning I'm still seeing problems. When you have a combination number/character sequence (i.e., 1D or 11-22+) and specify an alignment (flushleft/middle/flushright) spaces get inserted between the final digit and the first trailing character. So "1D" might print as "1 D", "11-22+" prints as "11-22 +", etc. This happens using "." or "," for alignment, it's not exclusive to aligning on a hyphen. I included a sample and some output below (good.pdf is from 2013.06.10, bad.pdf is 2014.06.22) Regards, Brian \starttext %\enabletrackers[typesetters.characteralign] \bgroup \setupTABLE[1,2][3,4,5,6,7,8][aligncharacter=yes,alignmentcharacter={-}] \bTABLE[align={flushleft}] \bTABLE \bTR \bTD xxxxxxxx \eTD \bTD xxxxxxxx \eTD\bTD xxxxxxxx \eTD \eTR \bTR \bTD xxxxx \eTD \bTD xxxxx \eTD\bTD xxxxx \eTD \eTR \bTR \bTD 1D \eTD \bTD 5D \eTD\bTD xxx \eTD \eTR \bTR \bTD 1-2 \eTD \bTD 1-2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 1-2+ \eTD \bTD 1-2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 1-2 \eTD \bTD 1-2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 11-2 \eTD \bTD 11-2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 11-22+ \eTD \bTD 11-22+ \eTD\bTD xxx \eTD \eTR \eTABLE \egroup \bgroup \setupTABLE[1,2][3,4,5,6,7,8][aligncharacter=yes,alignmentcharacter={-}] \bTABLE[align={middle}] \bTR \bTD xxxxxxxx \eTD \bTD xxxxxxxx \eTD\bTD xxxxxxxx \eTD \eTR \bTR \bTD xxxxx \eTD \bTD xxxxx \eTD\bTD xxxxx \eTD \eTR \bTR \bTD 1D \eTD \bTD 5D \eTD\bTD xxx \eTD \eTR \bTR \bTD 1-2 \eTD \bTD 1-2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 1-2+ \eTD \bTD 1-2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 1-2 \eTD \bTD 1-2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 11-2 \eTD \bTD 11-2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 11-22+ \eTD \bTD 11-22+ \eTD\bTD xxx \eTD \eTR \eTABLE \egroup \bgroup \setupTABLE[1,2][3,4,5,6,7,8][aligncharacter=yes,alignmentcharacter={-}] \bTABLE[align={flushright}] \bTR \bTD xxxxxxxx \eTD \bTD xxxxxxxx \eTD\bTD xxxxxxxx \eTD \eTR \bTR \bTD xxxxx \eTD \bTD xxxxx \eTD\bTD xxxxx \eTD \eTR \bTR \bTD 1D \eTD \bTD 5D \eTD\bTD xxx \eTD \eTR \bTR \bTD 1-2 \eTD \bTD 1-2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 1-2+ \eTD \bTD 1-2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 1-2 \eTD \bTD 1-2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 11-2 \eTD \bTD 11-2 \eTD\bTD xxx \eTD \eTR \bTR \bTD 11-22+ \eTD \bTD 11-22+ \eTD\bTD xxx \eTD \eTR \eTABLE \egroup \stoptext
On 6/26/2014 5:06 AM, Brian Landy wrote:
On Jun 25, 2014, at 6:53 PM, Hans Hagen
wrote: On 6/25/2014 11:26 PM, Brian R. Landy wrote:
When you say "next beta" do you mean a subsequent minimals release (i.e., this fix should be the 2014.06.22 release)? Or do you mean a new beta that you announce more formally on the list? I'm not sure what I should look for before I test again, so I don't end up testing a version without the fix.
netx beta == next upload == already done
Great, thanks. I wanted to make sure before mentioning I'm still seeing problems. When you have a combination number/character sequence (i.e., 1D or 11-22+) and specify an alignment (flushleft/middle/flushright) spaces get inserted between the final digit and the first trailing character. So "1D" might print as "1 D", "11-22+" prints as "11-22 +", etc. This happens using "." or "," for alignment, it's not exclusive to aligning on a hyphen.
i now have two methods, number and text and {-} triggers text you can force a method with text-> and number-> no upload yet ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 6/26/2014 10:48 PM, Hans Hagen wrote:
On 6/26/2014 5:06 AM, Brian Landy wrote:
On Jun 25, 2014, at 6:53 PM, Hans Hagen
wrote: On 6/25/2014 11:26 PM, Brian R. Landy wrote:
When you say "next beta" do you mean a subsequent minimals release (i.e., this fix should be the 2014.06.22 release)? Or do you mean a new beta that you announce more formally on the list? I'm not sure what I should look for before I test again, so I don't end up testing a version without the fix.
netx beta == next upload == already done
Great, thanks. I wanted to make sure before mentioning I'm still seeing problems. When you have a combination number/character sequence (i.e., 1D or 11-22+) and specify an alignment (flushleft/middle/flushright) spaces get inserted between the final digit and the first trailing character. So "1D" might print as "1 D", "11-22+" prints as "11-22 +", etc. This happens using "." or "," for alignment, it's not exclusive to aligning on a hyphen.
i now have two methods, number and text and {-} triggers text
you can force a method with text-> and number->
no upload yet
I'll also add \nocharacteralign so that one can disable this mechanism in a table cell. ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Jun 26, 2014, at 5:24 PM, Hans Hagen
On 6/26/2014 10:48 PM, Hans Hagen wrote:
On 6/26/2014 5:06 AM, Brian Landy wrote:
On Jun 25, 2014, at 6:53 PM, Hans Hagen
wrote: On 6/25/2014 11:26 PM, Brian R. Landy wrote:
When you say "next beta" do you mean a subsequent minimals release (i.e., this fix should be the 2014.06.22 release)? Or do you mean a new beta that you announce more formally on the list? I'm not sure what I should look for before I test again, so I don't end up testing a version without the fix.
netx beta == next upload == already done
Great, thanks. I wanted to make sure before mentioning I'm still seeing problems. When you have a combination number/character sequence (i.e., 1D or 11-22+) and specify an alignment (flushleft/middle/flushright) spaces get inserted between the final digit and the first trailing character. So "1D" might print as "1 D", "11-22+" prints as "11-22 +", etc. This happens using "." or "," for alignment, it's not exclusive to aligning on a hyphen.
i now have two methods, number and text and {-} triggers text
you can force a method with text-> and number->
no upload yet
I'll also add \nocharacteralign so that one can disable this mechanism in a table cell.
This is all great, thank's so much for handling this so quickly! I like the idea of keeping the old behavior as an alternative. And now that I see what your new mode is attempting to accomplish, I think it will prove very useful. It looks like you want to parse out the number from any preceding and following text, align the number on the alignment character, and pad out any text that precedes a number (like a currency symbol) to align on the left rather than be flush with the number. I just wanted to point out that this only works if identical preceding and/or trailing text exists in every cell. For example, this table doesn't align using flushleft, middle, or flushright (it will if you force text->{.}, but of course the parens won't align vertically): \starttext \bgroup< \setupTABLE[1,2][3,4,5,6][aligncharacter=yes,alignmentcharacter={.}] \bTABLE[align={flushright}] \bTR \bTD xxxxxxxx \eTD \eTR \bTR \bTD xxxxx \eTD \eTR \bTR \bTD 1.2 \eTD \eTR \bTR \bTD (1.2) \eTD \eTR \bTR \bTD 11.22 \eTD \eTR \bTR \bTD (11.22) \eTD \eTR \eTABLE \egroup \stoptext Without having looked through the code, I wonder if in number mode you could first run the existing logic, and then finish off using the existing text logic to pad the outside (i.e., to the left of the left-hand text and to the right of the right-hand text)? Anyway, for my purposes restoring the old mode as an option is perfect, I just wanted to mention this in case this wasn't the behavior you intended. Thanks again! Best regards, Brian
On 6/27/2014 8:04 PM, Brian Landy wrote:
On Jun 26, 2014, at 5:24 PM, Hans Hagen
wrote: On 6/26/2014 10:48 PM, Hans Hagen wrote:
On 6/26/2014 5:06 AM, Brian Landy wrote:
On Jun 25, 2014, at 6:53 PM, Hans Hagen
wrote: On 6/25/2014 11:26 PM, Brian R. Landy wrote:
When you say "next beta" do you mean a subsequent minimals release (i.e., this fix should be the 2014.06.22 release)? Or do you mean a new beta that you announce more formally on the list? I'm not sure what I should look for before I test again, so I don't end up testing a version without the fix.
netx beta == next upload == already done
Great, thanks. I wanted to make sure before mentioning I'm still seeing problems. When you have a combination number/character sequence (i.e., 1D or 11-22+) and specify an alignment (flushleft/middle/flushright) spaces get inserted between the final digit and the first trailing character. So "1D" might print as "1 D", "11-22+" prints as "11-22 +", etc. This happens using "." or "," for alignment, it's not exclusive to aligning on a hyphen.
i now have two methods, number and text and {-} triggers text
you can force a method with text-> and number->
no upload yet
I'll also add \nocharacteralign so that one can disable this mechanism in a table cell.
This is all great, thank's so much for handling this so quickly! I like the idea of keeping the old behavior as an alternative.
in fact, the old behaviour is the default for number related seperators but in your case the - so not a number separator so then it assumes text
And now that I see what your new mode is attempting to accomplish, I think it will prove very useful. It looks like you want to parse out the number from any preceding and following text, align the number on the alignment character, and pad out any text that precedes a number (like a currency symbol) to align on the left rather than be flush with the number. I just wanted to point out that this only works if identical preceding and/or trailing text exists in every cell.
indeed, this mechanism was meant for numbers
For example, this table doesn't align using flushleft, middle, or flushright (it will if you force text->{.}, but of course the parens won't align vertically):
\starttext \bgroup< \setupTABLE[1,2][3,4,5,6][aligncharacter=yes,alignmentcharacter={.}] \bTABLE[align={flushright}] \bTR \bTD xxxxxxxx \eTD \eTR \bTR \bTD xxxxx \eTD \eTR \bTR \bTD 1.2 \eTD \eTR \bTR \bTD (1.2) \eTD \eTR \bTR \bTD 11.22 \eTD \eTR \bTR \bTD (11.22) \eTD \eTR \eTABLE \egroup \stoptext
Without having looked through the code, I wonder if in number mode you could first run the existing logic, and then finish off using the existing text logic to pad the outside (i.e., to the left of the left-hand text and to the right of the right-hand text)?
not today ... things take time
Anyway, for my purposes restoring the old mode as an option is perfect, I just wanted to mention this in case this wasn't the behavior you intended.
maybe you can wikify these variants Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (3)
-
Brian Landy
-
Brian R. Landy
-
Hans Hagen