latest beta, problem with natural tables and alignment character

Brian Landy

16 Jun 2014 16 Jun '14

3:51 p.m.

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

Attachments:

test.tex (application/octet-stream — 2.6 KB)
good.pdf (application/pdf — 10.8 KB)
bad.pdf (application/pdf — 10.8 KB)
signature.asc (application/pgp-signature — 801 bytes)

Show replies by date

Hans Hagen

16 Jun 16 Jun

4:53 p.m.

New subject: latest beta, problem with natural tables and alignment character

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 -----------------------------------------------------------------

Hans Hagen

4:57 p.m.

New subject: latest beta, problem with natural tables and alignment character

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 -----------------------------------------------------------------

Brian Landy

9:49 p.m.

New subject: latest beta, problem with natural tables and alignment character

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 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 ___________________________________________________________________________________

Hans Hagen

17 Jun 17 Jun

4:56 a.m.

New subject: latest beta, problem with natural tables and alignment character

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

9:18 a.m.

New subject: latest beta, problem with natural tables and alignment character

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 -----------------------------------------------------------------

Brian Landy

9:18 p.m.

New subject: latest beta, problem with natural tables and alignment character

On Jun 17, 2014, at 11:18 AM, Hans Hagen wrote:

...

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

Brian R. Landy

25 Jun 25 Jun

3:26 p.m.

New subject: latest beta, problem with natural tables and alignment character

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

Hans Hagen

4:53 p.m.

New subject: latest beta, problem with natural tables and alignment character

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 -----------------------------------------------------------------

Brian Landy

9:06 p.m.

New subject: latest beta, problem with natural tables and alignment character

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 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

Hans Hagen

26 Jun 26 Jun

2:48 p.m.

New subject: latest beta, problem with natural tables and alignment character

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 -----------------------------------------------------------------

Hans Hagen

3:24 p.m.

New subject: latest beta, problem with natural tables and alignment character

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 -----------------------------------------------------------------

Brian Landy

27 Jun 27 Jun

12:04 p.m.

New subject: latest beta, problem with natural tables and alignment character

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. 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

Hans Hagen

12:16 p.m.

New subject: latest beta, problem with natural tables and alignment character

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 -----------------------------------------------------------------

3682

Age (days ago)

3693

Last active (days ago)

List overview

Download

13 comments

3 participants

participants (3)

Brian Landy
Brian R. Landy
Hans Hagen

latest beta, problem with natural tables and alignment character

tags

participants (3)