Re: [NTG-context] Strange behaviour of \bTABLE ... \eTABLE
Dear Mojca: I think I see what the problem is. If, instead of typing
\bTR\bTD a midaligned parbox: \eTD\bTD[offset=0pt,width=1em] % 1em wide paragraph 1 2 3 \eTD\eTR
you type 1\ 2\ 3\ you get what is wanted, namely, 1 2 3 My guess is that there is a built-in bias not to split a line but, rather, give you an overfull \hbox. I "forced" the issue by defining each column to be less than 1em (because "1" is a very narrow char that surely takes less than 1 em), and by adding a typescript space after each number. It might even be possible to eliminate the typescript space and simply define each column to be 0.25em, say, but I did not try it. Best, elena P.S. Let me know if I missed the boat entirely. This is the first issue I attempt to answer. Here is what I ran in LiveContext: \starttext \setupTABLE[frame=on] % only for debugging reasons \setupTABLE[c][each][align=lohi] % to center vertically (any better way?) \bTABLE \bTR\bTD[offset=0pt,width=0.5em] % 1em wide paragraph 1\ 2\ 3\ \eTD\eTR \eTABLE \stoptext
Hello,
On the wiki (http://contextgarden.net/Vertically_centred) a while ago someone asked how to do the following in ConTeXt:
%%%%%%
\documentclass{article} \begin{document} a box with a table: \fbox{\begin{tabular}[c]{l}1\\2\\3\end{tabular}}\par
a midaligned parbox: \parbox[c]{1em}{1 2 3} \end{document}
%%%%%%
I don't know if this would be the proper solution, but for the second case (\parbox[c]{1em}{...} which should make a paragraph 1 em wide and center the paragraph box vertically) I tried the following:
%%%%%%
\setupTABLE[frame=on] % only for debugging reasons \setupTABLE[c][1,2][align=lohi] % to center vertically (any better way?) \bTABLE \bTR\bTD a midaligned parbox: \eTD\bTD[offset=0pt,width=1em] % 1em wide paragraph 1 2 3 \eTD\eTR \eTABLE
%%%%%%
My ConTeXt version is 2005.06.27. See the vcenter-context-old.png for the result.
The strange thing is that the number 2 is still in the first line, although it is too wide.
Even more strange, I tried the same on live.contextgarden.net. See vcenter-context-new.png for the result.
vcenter-latex.tex is what the result should be.
-------------------------------------------------------------------
This also results in a mess on the live.contextgarden.net:
\bTABLE \bTR\bTD {\bTABLE \bTR\bTD whatever \eTD\eTR \eTABLE} \eTD\eTR \eTABLE
Mojca
Elena Fraboschi wrote:
My guess is that there is a built-in bias not to split a line but, rather, give you an overfull \hbox. I "forced" the issue by defining each column to be less than 1em (because "1" is a very narrow char that surely takes less than 1 em), and by adding a typescript space after each number. It might even be possible to eliminate the typescript space and simply define each column to be 0.25em, say, but I did not try it.
It may actually be that the penalty for an underfull box is bigger than for the overfull one. This explains strange placing of the numbers then. ... but in the latest ConTeXt version it looks as if it wouldn't work at all. ----------------------------------------------- It is perhaps a lot of work included, but extending the contextgarden.net in such a way that users could provide test cases which would be typeset with different ConTeXt versions and PNGs compared afterwards ... could make it easier to discover any broken functionality. Mojca
Am 2005-07-25 um 22:04 schrieb Mojca Miklavec:
It is perhaps a lot of work included, but extending the contextgarden.net in such a way that users could provide test cases which would be typeset with different ConTeXt versions and PNGs compared afterwards ... could make it easier to discover any broken functionality.
Oh, another quest for our magic Patrick! ;-) Let me extend the suggestion, for we miss a ConTeXt test suite for a long time now: - users send test cases - test cases get typeset with the actual ConTeXt and converted to PNG (like inline samples) - user "votes" if it looks right, if not adds comment - test case gets saved, including PNG, ConTeXt version and vote/comments - at next update, all test cases get typeset again, and users can "vote" if it looks still ok or at least the same (perhaps it would be possible to check automatically if the bitmaps are exactly identical) This does work only for max. 1 page samples, and I don't know if it's within the abilities of our wizard(s)... And I guess different users have different opinions what looks "right", but we could check if something changed. Grüßlis vom Hraban! --- http://www.fiee.net/texnique/ http://contextgarden.net
Henning Hraban Ramm wrote:
Am 2005-07-25 um 22:04 schrieb Mojca Miklavec:
It is perhaps a lot of work included, but extending the contextgarden.net in such a way that users could provide test cases which would be typeset with different ConTeXt versions and PNGs compared afterwards ... could make it easier to discover any broken functionality.
Oh, another quest for our magic Patrick! ;-)
Let me extend the suggestion, for we miss a ConTeXt test suite for a long time now:
- users send test cases - test cases get typeset with the actual ConTeXt and converted to PNG (like inline samples) - user "votes" if it looks right, if not adds comment - test case gets saved, including PNG, ConTeXt version and vote/comments - at next update, all test cases get typeset again, and users can "vote" if it looks still ok or at least the same (perhaps it would be possible to check automatically if the bitmaps are exactly identical)
This does work only for max. 1 page samples, and I don't know if it's within the abilities of our wizard(s)... And I guess different users have different opinions what looks "right", but we could check if something changed.
i'd say, go ahead ... you can use the wiki as place to collect those things Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
It is perhaps a lot of work included, but extending the contextgarden.net in such a way that users could provide test cases which would be typeset with different ConTeXt versions and PNGs compared afterwards ... could make it easier to discover any broken functionality.
It comes down to: * different context versions needed * different test documents needed 1) user can select any combination of the above 2) result (one page/png, more pages pdf) can be viewed or downloaded 3) feedback or perhaps (as I can read between your lines) a pdf with even number of pages: left page: original, right page the selcted version. So we need test documents and after that context can mix in the pages from the known good document and the selecte version. So you think that users actually download these comparisons?
Oh, another quest for our magic Patrick! ;-)
Don't call me magic. I am currently trying to understand the tftopl, pltotf, vftovp and vptovf programs in detail. And I am so miserable at that; all kinds of optimizations that makes the code unreadable.
Let me extend the suggestion, for we miss a ConTeXt test suite for a long time now:
- users send test cases - test cases get typeset with the actual ConTeXt and converted to PNG (like inline samples) - user "votes" if it looks right, if not adds comment - test case gets saved, including PNG, ConTeXt version and vote/comments - at next update, all test cases get typeset again, and users can "vote" if it looks still ok or at least the same (perhaps it would be possible to check automatically if the bitmaps are exactly identical)
Again, I doubt that users will actually do these kind of things. I could provide some interface for documents connected to version numbers, so you could download a set of .tex files (or one big tex file) and the related pdf file, but we need to collect good examples. And I think that testing is very hard: there are so many different things in ConTeXt that can be tested, so the pdf would result in a few hundred pages. Patrick -- ConTeXt wiki and more: http://contextgarden.net
Patrick Gundlach wrote:
It is perhaps a lot of work included, but extending the contextgarden.net in such a way that users could provide test cases which would be typeset with different ConTeXt versions and PNGs compared afterwards ... could make it easier to discover any broken functionality.
It comes down to:
* different context versions needed
Once you are done with the fonts ... Different ConTeXt versions also seem to be useful for all kinds of stuff: - browsing (& comparing) old source files - running live.contextgarden.net on older versions (in case the behaviour in the new version is changed) - (maybe donloading old ConTeXt versions for whatever reason?) - modules.pdf - test suite
* different test documents needed
This can be done gradually. Of course, it is impossible to have a very good test suite, but at least some features can be tested; broken functionality would be noted much later otherwise (if ever). If you let the users add stuff, the suit will gradually grow. It would be much easier then to say "take a look: my document is OK with the version this-and-that, but since the version this-and-that something strange happens" when reporting a bug. (Perhaps testing documents should also have at least some very basic set of labels: very important to test, interesting test case, just temporary or one-time testing. Or at least some switch to leave the document there, but to remove it from the list of "test suite" when next ConTeXt version is out. 100 versions and 1000 documents ... can slow down your computer a bit.)
1) user can select any combination of the above 2) result (one page/png, more pages pdf) can be viewed or downloaded
Converting multiple-page pdf to png-s should also be possible. Take http://archive.contextgarden.net/thread/20050701.172657.13cd3fb5.html for example (the difference seen on the third page). But the number of pages or at least the number of document with a big number of pages has to be limited somehow.
3) feedback
Perhaps some labeling in case the results differ? - Label A: to inspect what's going wrong - Label B: it's ok, it's only a new feature, not supported before - Label C: ok, the bug was removed (some page inbetween differ) - Label D: ... Only the label A and perhaps some others would be interesting then ...
So we need test documents and after that context can mix in the pages from the known good document and the selecte version.
So you think that users actually download these comparisons?
The most important would be some graphical representation (different colors if a document doesn't compile or if it changes), but allowing the user to download a selected document compiled with a selected version should be possible.
Don't call me magic. I am currently trying to understand the tftopl, pltotf, vftovp and vptovf programs in detail. And I am so miserable at that; all kinds of optimizations that makes the code unreadable.
:)
Let me extend the suggestion, for we miss a ConTeXt test suite for a long time now:
- users send test cases - test cases get typeset with the actual ConTeXt and converted to PNG (like inline samples) - user "votes" if it looks right, if not adds comment - test case gets saved, including PNG, ConTeXt version and vote/comments - at next update, all test cases get typeset again, and users can "vote" if it looks still ok or at least the same (perhaps it would be possible to check automatically if the bitmaps are exactly identical)
Again, I doubt that users will actually do these kind of things. I could provide some interface for documents connected to version numbers, so you could download a set of .tex files (or one big tex file) and the related pdf file, but we need to collect good examples. And I think that testing is very hard: there are so many different things in ConTeXt that can be tested, so the pdf would result in a few hundred pages.
No, this wouldn't make any sense. I was thinking about PDF to PNG conversion and bitwise comparison of the files, which could be made automatically. Each time a new version would be uploaded, the documents would be compiled, any compilation errors caught and any image differences reported. Only if any of those two cases would be reported, the results would be inspected manually. Sorry Patrick :), Mojca
[...]
No, this wouldn't make any sense. I was thinking about PDF to PNG conversion and bitwise comparison of the files, which could be made automatically. Each time a new version would be uploaded, the documents would be compiled, any compilation errors caught and any image differences reported. Only if any of those two cases would be reported, the results would be inspected manually.
Anybody needs a subject for his (or her!!!) masters thesis? Patrick -- ConTeXt wiki and more: http://contextgarden.net
Patrick Gundlach wrote:
Don't call me magic. I am currently trying to understand the tftopl, pltotf, vftovp and vptovf programs in detail. And I am so miserable at that; all kinds of optimizations that makes the code unreadable.
I've spent the better part of the last week trying to come to terms with the eq_define() and unsave() routines in TeX, so I can relate to that :-/ Taco
Mojca Miklavec wrote:
It may actually be that the penalty for an underfull box is bigger than for the overfull one. This explains strange placing of the numbers then.
let's eee what taco says ... our tex source magician may knows the dirty details
... but in the latest ConTeXt version it looks as if it wouldn't work at all.
eh ... what exactly does not work in the latest Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Hans Hagen wrote:
Mojca Miklavec wrote:
It may actually be that the penalty for an underfull box is bigger than for the overfull one. This explains strange placing of the numbers then.
let's eee what taco says ... our tex source magician may knows the dirty details
lines that cannot stretch far enough are skipped. Lines that cannot shrink far enough are unsolvable, and therefore remain present. Taco
Elena Fraboschi wrote:
Dear Mojca:
I think I see what the problem is. If, instead of typing
\bTR\bTD a midaligned parbox: \eTD\bTD[offset=0pt,width=1em] % 1em wide paragraph 1 2 3 \eTD\eTR
you type 1\ 2\ 3\
you get what is wanted, namely,
1 2 3
My guess is that there is a built-in bias not to split a line but, rather, give you an overfull \hbox. I "forced" the issue by defining each column to be less than 1em (because "1" is a very narrow char that surely takes less than 1 em), and by adding a typescript space after each number. It might even be possible to eliminate the typescript space and simply define each column to be 0.25em, say, but I did not try it. Best, elena
P.S. Let me know if I missed the boat entirely. This is the first issue I attempt to answer.
Here is what I ran in LiveContext:
\starttext \setupTABLE[frame=on] % only for debugging reasons \setupTABLE[c][each][align=lohi] % to center vertically (any better way?) \bTABLE \bTR\bTD[offset=0pt,width=0.5em] % 1em wide paragraph 1\ 2\ 3\ \eTD\eTR \eTABLE \stoptext
Hello,
On the wiki (http://contextgarden.net/Vertically_centred) a while ago someone asked how to do the following in ConTeXt:
%%%%%%
\documentclass{article} \begin{document} a box with a table: \fbox{\begin{tabular}[c]{l}1\\2\\3\end{tabular}}\par
a midaligned parbox: \parbox[c]{1em}{1 2 3} \end{document}
%%%%%%
I don't know if this would be the proper solution, but for the second case (\parbox[c]{1em}{...} which should make a paragraph 1 em wide and center the paragraph box vertically) I tried the following:
%%%%%%
\setupTABLE[frame=on] % only for debugging reasons \setupTABLE[c][1,2][align=lohi] % to center vertically (any better way?) \bTABLE \bTR\bTD a midaligned parbox: \eTD\bTD[offset=0pt,width=1em] % 1em wide paragraph 1 2 3 \eTD\eTR \eTABLE
%%%%%%
My ConTeXt version is 2005.06.27. See the vcenter-context-old.png for the result.
The strange thing is that the number 2 is still in the first line, although it is too wide.
Even more strange, I tried the same on live.contextgarden.net. See vcenter-context-new.png for the result.
vcenter-latex.tex is what the result should be.
-------------------------------------------------------------------
This also results in a mess on the live.contextgarden.net:
\bTABLE \bTR\bTD {\bTABLE \bTR\bTD whatever \eTD\eTR \eTABLE} \eTD\eTR \eTABLE
Mojca
_______________________________________________ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
-- ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (6)
-
Elena Fraboschi -
Hans Hagen -
Henning Hraban Ramm -
Mojca Miklavec -
Patrick Gundlach -
Taco Hoekwater