Re: [NTG-context] MK-II to MK-IV
Hi,
In reply to Hans, I am using the latest beta (ConTeXt version 2010.02.25
19:46.
mkiv, LuaTeX version 50, LuaTeX revision 0, (LuaTeX date stamp 2009122521))
As Hans requested a small test file,
\setupnumbering[way=bysection] % --- this used to work, but does not
\setupformulas[numbercolor=blue,numberstyle=bold]
\starttext
\chapter{Math formulae numbering}
\section{Does not work}
Numbering formulae by section
\placeformula
\startformula
a^2 + b^2 = c^2
\stopformula
\section{More ...}
\stoptext
Also tried the solution from Contextgarden (
http://wiki.contextgarden.net/Math/Display) by using
\setupnumber[formula][way=bysection] instead of \setupnumbering[way=bysection]
But alas, this does not work either
On Sun, Feb 28, 2010 at 3:47 AM, gummybears oracle...@gmail.com wrote:
Hi,
A couple of years ago, I decided to switch from LaTex to ConText. Now
I have compiled a lot of documents (Physics syllabi's) which compiles fine
in MK-II.
I thought I would try to make a switch to MK-IV, mainly because I
want to include 3D PRC figures in my documents.
I made some test cases to test MK-IV in order to get a handle on the
differences between MK-II and MK-IV
Some of my observations are
*) Numbered formulas, numbered by section, don't seem to work
*) I am getting a lot of warnings of identifiers, apparently used more than
once, which they are not
LuaTeX warning (ext4): destination with the same identifier
(name{km1_chapter1_sec1}) has been already used, duplicate ignored
Question
Are these observations correct, someone else can confirm them ?
Question
If so, is there a fix, patch, or change in ConText commands/options I am
not aware of ?
TIA
___
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
___
[NTG-context] MkIV gray, no MkII black ?
Hi, in MkII I set \setupcolors[state=start] to activate defined colors (for text, numbers etc.), and \setupcolors[state=stop] to set these colors to black. Now, in MkIV \setupcolors[state=stop] does set these colors to gray. Not to black. [Log: color : system gray is global activated] What is the key to set either color is color or color is black again? Steffen ___ 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 ___
Re: [NTG-context] MkIV gray, no MkII black ?
Hi Steffen, Am 01.03.2010 13:41, schrieb Steffen Wolfrum: Hi, in MkII I set \setupcolors[state=start] to activate defined colors (for text, numbers etc.), and \setupcolors[state=stop] to set these colors to black. Now, in MkIV \setupcolors[state=stop] does set these colors to gray. Not to black. [Log: color : system gray is global activated] What is the key to set either color is color or color is black again? i don't think mkiv has such an option (but maybe i'm wrong). how about defining some color palettes then? this should work with both marks. \definepalet[coloredtext][...] \setuppalet[coloredtext] \startmode[black] \definepalet[blacktext] [red=black, blue=black,...] \setuppalet[blacktext] \stopmode Best wishes, Peter Steffen ___ 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 ___
Re: [NTG-context] MK-II to MK-IV
Am 01.03.10 09:39, schrieb gummybears: Hi, In reply to Hans, I am using the latest beta (ConTeXt version 2010.02.25 19:46. mkiv, LuaTeX version 50, LuaTeX revision 0, (LuaTeX date stamp 2009122521)) As Hans requested a small test file, \setupnumbering[way=bysection] % --- this used to work, but does not \setupformulas[numbercolor=blue,numberstyle=bold] \definestructureprefixset[section][section-3][] \setupformulas[numbercolor=blue,numberstyle=bold,prefixset=section] Wolfgang ___ 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 ___
[NTG-context] METAPOST's superellipse with superness0.5 does not give a superellipse
Hi again,
Another METAPOST problem. For the sake of curiosity, I've been looking at
and playing with the superellipse() function in plain METAPOST. This is all
fine and dandy until I try values of 'superness' less than 0.5, in which
case it generates shapes that are seemingly not superellipses. At s=0.5,
the function generates a diamond shape -- which, AFAIK, is correct.
However, s0.5, the points of the diamond immediately turn to curves. (My
knowledge of superellipses here is just from
http://en.wikipedia.org/wiki/Superellipse -- try the image at
http://en.wikipedia.org/wiki/File:Lame_anima.gif to see how I expect the
shape to change with varying values of superness).
Some code follows -- perhaps someone could run it and tell me if, for
starters, they get the same as me. (See
http://i49.tinypic.com/2ijqatl.jpgfor superellipse() with s=0.3).
Best,
James
% The following is a superellipse function at
http://lists.foundry.supelec.fr/pipermail/metapost-commits/2008-June/000340.html
;
% I think it's the superellipse function in my copy of METAPOST; it at least
has the same behaviour.
% It seems to calculate the vertices correctly, but not the way they join
(try changing all ... to --).
%
%def superellipse(expr r,t,l,b,s)=
% r ... (s[xpart t,xpart r],s[ypart r,ypart t]){t-r} ...
% t ... (s[xpart t,xpart l],s[ypart l,ypart t]){l-t} ...
% l ... (s[xpart b,xpart l],s[ypart l,ypart b]){b-l} ...
% b ... (s[xpart b,xpart r],s[ypart r,ypart b]){r-b} ... cycle
%enddef;
def supertest expr s =
superellipse(
( 100, 50 ),
( 50, 100 ),
( 0, 50 ),
( 50, 0 ),
s
);
enddef;
% These 0 supernesses are fine, I think ...
beginfig(0);
draw supertest 2;
endfig;
beginfig(1);
draw supertest 1.01;
endfig;
% The following, 0.5=superness=1,
% are from visual reference definitely right
beginfig(2);
draw supertest 1;
endfig;
beginfig(3);
draw supertest 0.99;
endfig;
beginfig(4);
draw supertest 0.7;
endfig;
beginfig(5);
draw supertest 0.51;
endfig;
beginfig(6);
draw supertest 0.5;
endfig;
% Now, for 0.5,
% things get problematic --
% the points in the shape generated by s=0.5
% should stay 'pointy'
beginfig(7);
draw supertest 0.49;
endfig;
beginfig(8);
draw supertest 0.3;
endfig;
beginfig(9);
draw supertest 0.01;
endfig;
beginfig(10);
draw supertest 0;
endfig;
end;
___
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
___
Re: [NTG-context] MkIV gray, no MkII black ?
On 1-3-2010 15:02, Peter Rolf wrote: Hi Steffen, Am 01.03.2010 13:41, schrieb Steffen Wolfrum: Hi, in MkII I set \setupcolors[state=start] to activate defined colors (for text, numbers etc.), and \setupcolors[state=stop] to set these colors to black. Now, in MkIV \setupcolors[state=stop] does set these colors to gray. Not to black. [Log: color : system gray is global activated] What is the key to set either color is color or color is black again? i don't think mkiv has such an option (but maybe i'm wrong). how about defining some color palettes then? this should work with both marks. \definepalet[coloredtext][...] \setuppalet[coloredtext] \startmode[black] \definepalet[blacktext] [red=black, blue=black,...] \setuppalet[blacktext] \stopmode as colorspace info travels indepently you can say \attribute\colormodelattribute\attributeunsetvalue i'll add \setupcolors[state=stop,conversion=never] - 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 - ___ 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 ___
Re: [NTG-context] METAPOST's superellipse with superness0.5 does not give a superellipse
I should say that the vertices of the superellipse are calculated
correctly. The problem, it seems, is that for the vertices at right, top,
left, and bottom, the angles of entry and exit need to be explicitly
defined, rather than just relying on the '...' which coincidentally works
for s=0.5.
I should say at this point that I am no maths whiz. But, sticking with the
'right ... topright ... top' line, the angle calculation needs to satisfy,
for the exit angle of the first vertex:
For s=0, angle = 180 degrees (vector to the left)
For s = 0.5, angle = 135 degrees (45 degrees to the top left, producing a
straight line to create the diamond shape)
For s0.5, angle = 90 degrees (vector vertically upwards)
Suffice to say that I don't know how to produce that elegantly.
James
On Mon, Mar 1, 2010 at 3:54 PM, James Fisher jameshfis...@gmail.com wrote:
Hi again,
Another METAPOST problem. For the sake of curiosity, I've been looking at
and playing with the superellipse() function in plain METAPOST. This is all
fine and dandy until I try values of 'superness' less than 0.5, in which
case it generates shapes that are seemingly not superellipses. At s=0.5,
the function generates a diamond shape -- which, AFAIK, is correct.
However, s0.5, the points of the diamond immediately turn to curves. (My
knowledge of superellipses here is just from
http://en.wikipedia.org/wiki/Superellipse -- try the image at
http://en.wikipedia.org/wiki/File:Lame_anima.gif to see how I expect the
shape to change with varying values of superness).
Some code follows -- perhaps someone could run it and tell me if, for
starters, they get the same as me. (See
http://i49.tinypic.com/2ijqatl.jpg for superellipse() with s=0.3).
Best,
James
% The following is a superellipse function at
http://lists.foundry.supelec.fr/pipermail/metapost-commits/2008-June/000340.html
;
% I think it's the superellipse function in my copy of METAPOST; it at
least has the same behaviour.
% It seems to calculate the vertices correctly, but not the way they join
(try changing all ... to --).
%
%def superellipse(expr r,t,l,b,s)=
% r ... (s[xpart t,xpart r],s[ypart r,ypart t]){t-r} ...
% t ... (s[xpart t,xpart l],s[ypart l,ypart t]){l-t} ...
% l ... (s[xpart b,xpart l],s[ypart l,ypart b]){b-l} ...
% b ... (s[xpart b,xpart r],s[ypart r,ypart b]){r-b} ... cycle
%enddef;
def supertest expr s =
superellipse(
( 100, 50 ),
( 50, 100 ),
( 0, 50 ),
( 50, 0 ),
s
);
enddef;
% These 0 supernesses are fine, I think ...
beginfig(0);
draw supertest 2;
endfig;
beginfig(1);
draw supertest 1.01;
endfig;
% The following, 0.5=superness=1,
% are from visual reference definitely right
beginfig(2);
draw supertest 1;
endfig;
beginfig(3);
draw supertest 0.99;
endfig;
beginfig(4);
draw supertest 0.7;
endfig;
beginfig(5);
draw supertest 0.51;
endfig;
beginfig(6);
draw supertest 0.5;
endfig;
% Now, for 0.5,
% things get problematic --
% the points in the shape generated by s=0.5
% should stay 'pointy'
beginfig(7);
draw supertest 0.49;
endfig;
beginfig(8);
draw supertest 0.3;
endfig;
beginfig(9);
draw supertest 0.01;
endfig;
beginfig(10);
draw supertest 0;
endfig;
end;
___
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
___
Re: [NTG-context] METAPOST's superellipse with superness0.5 does not give a superellipse
James's explanation appears to be right.
On p 126 of the METAFONTbook Knuth says that the superness should be
between 0.5 (when you get a diamond) and 1.0 (when you get a square).
Exercise 14.6 asks the reader to Try superellimpse with superness
values less than 0.5 or greater than 1.0; explain why you get weird
shapes in such cases. The answer is There are inflection points,
because there are no bounding triangles for the '...' operations in
the superellipse macro ... unless 0.5 \leq s \leq 1.
Cheers,
Rory
On Mon, Mar 1, 2010 at 8:04 AM, James Fisher jameshfis...@gmail.com wrote:
I should say that the vertices of the superellipse are calculated
correctly. The problem, it seems, is that for the vertices at right, top,
left, and bottom, the angles of entry and exit need to be explicitly
defined, rather than just relying on the '...' which coincidentally works
for s=0.5.
I should say at this point that I am no maths whiz. But, sticking with the
'right ... topright ... top' line, the angle calculation needs to satisfy,
for the exit angle of the first vertex:
For s=0, angle = 180 degrees (vector to the left)
For s = 0.5, angle = 135 degrees (45 degrees to the top left, producing a
straight line to create the diamond shape)
For s0.5, angle = 90 degrees (vector vertically upwards)
Suffice to say that I don't know how to produce that elegantly.
James
On Mon, Mar 1, 2010 at 3:54 PM, James Fisher jameshfis...@gmail.com wrote:
Hi again,
Another METAPOST problem. For the sake of curiosity, I've been looking at
and playing with the superellipse() function in plain METAPOST. This is all
fine and dandy until I try values of 'superness' less than 0.5, in which
case it generates shapes that are seemingly not superellipses. At s=0.5,
the function generates a diamond shape -- which, AFAIK, is correct.
However, s0.5, the points of the diamond immediately turn to curves. (My
knowledge of superellipses here is just from
http://en.wikipedia.org/wiki/Superellipse -- try the image at
http://en.wikipedia.org/wiki/File:Lame_anima.gif to see how I expect the
shape to change with varying values of superness).
Some code follows -- perhaps someone could run it and tell me if, for
starters, they get the same as me. (See http://i49.tinypic.com/2ijqatl.jpg
for superellipse() with s=0.3).
Best,
James
% The following is a superellipse function at
http://lists.foundry.supelec.fr/pipermail/metapost-commits/2008-June/000340.html;
% I think it's the superellipse function in my copy of METAPOST; it at
least has the same behaviour.
% It seems to calculate the vertices correctly, but not the way they join
(try changing all ... to --).
%
%def superellipse(expr r,t,l,b,s)=
% r ... (s[xpart t,xpart r],s[ypart r,ypart t]){t-r} ...
% t ... (s[xpart t,xpart l],s[ypart l,ypart t]){l-t} ...
% l ... (s[xpart b,xpart l],s[ypart l,ypart b]){b-l} ...
% b ... (s[xpart b,xpart r],s[ypart r,ypart b]){r-b} ... cycle
%enddef;
def supertest expr s =
superellipse(
( 100, 50 ),
( 50, 100 ),
( 0, 50 ),
( 50, 0 ),
s
);
enddef;
% These 0 supernesses are fine, I think ...
beginfig(0);
draw supertest 2;
endfig;
beginfig(1);
draw supertest 1.01;
endfig;
% The following, 0.5=superness=1,
% are from visual reference definitely right
beginfig(2);
draw supertest 1;
endfig;
beginfig(3);
draw supertest 0.99;
endfig;
beginfig(4);
draw supertest 0.7;
endfig;
beginfig(5);
draw supertest 0.51;
endfig;
beginfig(6);
draw supertest 0.5;
endfig;
% Now, for 0.5,
% things get problematic --
% the points in the shape generated by s=0.5
% should stay 'pointy'
beginfig(7);
draw supertest 0.49;
endfig;
beginfig(8);
draw supertest 0.3;
endfig;
beginfig(9);
draw supertest 0.01;
endfig;
beginfig(10);
draw supertest 0;
endfig;
end;
___
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
___
Re: [NTG-context] Math in MKIV - HOWTO
Hi, I got some time today and checked some symbols of hlcra.tfm
(LucidaNewMath-Arrows), and got this table:
fonts.enc.math[lucida-ma] = {
[0x025CB] = 0x00, -- circle
[0x025CF] = 0x01, -- blackcircle
[0x025A1] = 0x02, -- square
[0x025A0] = 0x03, -- blacksquare
[0x025B3] = 0x04, -- triangleup
[0x025B2] = 0x05, -- blacktriangleup
[0x025BD] = 0x06, -- triangledown
[0x025BC] = 0x07, -- blacktriangledown
[0x02B28] = 0x08, -- lozenge
[0x02B27] = 0x09, -- blacklozenge
[0x02B29] = 0x0A, -- blackdiamond
[0x02571] = 0x0B, -- upright
[0x02572] = 0x0C, -- downright
[0x022E4] = 0x0D, -- squareimageofnoteq
[0x022E5] = 0x0E, -- squareoriginalofnoteq
[0x02A4F] = 0x0F, -- dblsquareunion
[0x02A4E] = 0x10, -- dblsquareintersection
[0x02A64] = 0x11, -- zdomainantirestriction
[0x02A65] = 0x12, -- zrangeantirestriction
[0x022EE] = 0x13, -- verticalellipsis
[0x022EF] = 0x14, -- ellipsis
[0x022F0] = 0x15, -- uprightellipsis
[0x022F1] = 0x16, -- downrightellipsis
[0x022D5] = 0x17, -- equalparallel
[0x0225B] = 0x1A, -- stareq
[0x00127] = 0x1B, -- hbar
[0x022F6] = 0x1C, -- barelementof
[0x02209] = 0x1D, -- notelementof
[0x022FD] = 0x1E, -- barcontains
[0x0220C] = 0x1F, -- notcontain
[0x02204] = 0x20, -- nexists
[0x02194] = 0x21, -- leftrightarrow
[0x02195] = 0x22, -- updownarrow
[0x0219E] = 0x23, -- leftleftarrow
[0x0219F] = 0x24, -- upuparrow
[0x021A0] = 0x25, -- rightrightarrow
--~ [0x00026] = 0x26, -- amperand
[0x021A1] = 0x27, -- downdownarrow
[0x021A2] = 0x28, -- leftarrowtail
[0x021A3] = 0x29, -- rightarrowtail
[0x021A4] = 0x2A, -- leftarrowbar
[0x021A6] = 0x2B, -- rightarrowbar
[0x021A5] = 0x2C, -- uparrowbar
--~ [0x02212] = 0x2D, -- minus
--~ [0x0002D] = 0x2D, -- minus
[0x021A7] = 0x2E, -- downarrowbar
[0x021E4] = 0x2F, -- barleftarrow
[0x021E5] = 0x30, -- barrightarrow
[0x021E0] = 0x38, -- dashleftarrow
[0x021E1] = 0x39, -- dashuparrow
[0x021E2] = 0x3A, -- dashrightarrow
[0x021E3] = 0x3B, -- dashdownarrow
[0x021A9] = 0x3C, -- hookleftarrow
--~ [0x0003D] = 0x3D, -- equalto
[0x021AA] = 0x3E, -- hookrightarrow
[0x021AB] = 0x3F, -- looparrowleft
[0x021AC] = 0x40, -- looparrowright
[0x1D538] = 0x41, -- A (blackboard A)
[0x1D539] = 0x42, -- B
[0x02102] = 0x43, -- C
[0x1D53B] = 0x44, -- D
[0x1D53C] = 0x45, -- E
[0x1D53D] = 0x46, -- F
[0x1D53E] = 0x47, -- G
[0x0210D] = 0x48, -- H
[0x1D540] = 0x49, -- I
[0x1D541] = 0x4A, -- J
[0x1D542] = 0x4B, -- K
[0x1D543] = 0x4C, -- L
[0x1D544] = 0x4D, -- M
[0x02115] = 0x4E, -- N
[0x1D546] = 0x4F, -- O
[0x02119] = 0x50, -- P
[0x0211A] = 0x51, -- Q
[0x0211D] = 0x52, -- R
[0x1D54A] = 0x53, -- S
[0x1D54B] = 0x54, -- T
[0x1D54C] = 0x55, -- U
[0x1D54D] = 0x56, -- V
[0x1D54E] = 0x57, -- W
[0x1D54F] = 0x58, -- X
[0x1D550] = 0x59, -- Y
[0x02124] = 0x5A, -- Z (blackboard Z)
[0x0231C] = 0x5B, -- ulcorner
[0x0231D] = 0x5C, -- urcorner
[0x0231E] = 0x5D, -- llcorner
[0x0231F] = 0x5E, -- lrcorner
[0x02225] = 0x5F, -- parallel, Vert, lVert, rVert, arrowvert
[0x021D5] = 0x60, -- Updownarrow
[0x021D4] = 0x61, -- Leftrightarrow
[0x021D6] = 0x62, -- Upleftarrow
[0x021D7] = 0x63, -- Uprightarrow
[0x021D9] = 0x64, -- Downleftarrow
[0x021D5] = 0x65, -- Downrightarrow
[0x021CD] = 0x66, -- nLeftarrow
[0x021CE] = 0x67, -- nLeftrightarrow
[0x021CF] = 0x68, -- nRightarrow
--~ [0x021CE] = 0x69, -- nLeftrightarrow -- what's the difference
between this and 0x0067[0x021CE]
[0x021DA] = 0x6A, -- Lleftarrow
[0x1D55C] = 0x6B, -- k \Bbbk (blackboard k)
[0x021DB] = 0x6C, -- Rrightarrow
[0x021C4] = 0x6D, -- rlarrow
[0x021C6] = 0x6E, -- lrarrow
[0x021C5] = 0x6F, -- udarrow
--~ [0x021C5] = 0x70, -- duarrow
[0x021C7] = 0x71, -- llarrow
[0x021C8] = 0x72, -- uuarrow
[0x021C9] = 0x73, -- rrarrow
[0x021CA] = 0x74, -- ddarrow
[0x021BE] = 0x75, -- rupharpoon
[0x021BF] = 0x76, -- lupharpoon
[0x021C2] = 0x77, -- rdownharpoon
[0x021C3] = 0x78, -- ldownharpoon
[0x021CB] = 0x79, -- lrharpoon
[0x021CC] = 0x7A, -- rlharpoon
[0x021B0] = 0x7B, -- upthenleftarrow
--~ [0x0] = 0x7C, -- part
[0x021B1] = 0x7D, -- upthenrightarrow
--~ [0x0] = 0x7E, -- part
[0x02276] = 0x7F, -- ltgt
[0x021B2] = 0x81, -- downthenleftarrow
[0x021B3] = 0x82, -- downthenrightarrow
[0x02B0E] = 0x83, -- rightthendownarrow
[0x02B10] = 0x84, -- leftthendownarrow
[0x02B0F] = 0x85, -- rightthenuparrow
[0x02B11] = 0x86, -- leftthenuparrow
[0x021B6] = 0x87, -- leftarcarrow
[0x021B7] = 0x88, -- rightarcarrow
[0x0293D] = 0x89, -- leftarcarrowplus
[0x0293C] = 0x8A,
Re: [NTG-context] Math in MKIV - HOWTO
Correction:
[0x021D5] = 0x65, -- Downrightarrow
It's wrong, should be:
[0x021D8] = 0x65, -- Downrightarrow
On Tue, Mar 2, 2010 at 12:26 AM, Zhichu Chen zhichu.c...@gmail.com wrote:
Hi, I got some time today and checked some symbols of hlcra.tfm
(LucidaNewMath-Arrows), and got this table:
fonts.enc.math[lucida-ma] = {
[0x025CB] = 0x00, -- circle
[0x025CF] = 0x01, -- blackcircle
[0x025A1] = 0x02, -- square
[0x025A0] = 0x03, -- blacksquare
[0x025B3] = 0x04, -- triangleup
[0x025B2] = 0x05, -- blacktriangleup
[0x025BD] = 0x06, -- triangledown
[0x025BC] = 0x07, -- blacktriangledown
[0x02B28] = 0x08, -- lozenge
[0x02B27] = 0x09, -- blacklozenge
[0x02B29] = 0x0A, -- blackdiamond
[0x02571] = 0x0B, -- upright
[0x02572] = 0x0C, -- downright
[0x022E4] = 0x0D, -- squareimageofnoteq
[0x022E5] = 0x0E, -- squareoriginalofnoteq
[0x02A4F] = 0x0F, -- dblsquareunion
[0x02A4E] = 0x10, -- dblsquareintersection
[0x02A64] = 0x11, -- zdomainantirestriction
[0x02A65] = 0x12, -- zrangeantirestriction
[0x022EE] = 0x13, -- verticalellipsis
[0x022EF] = 0x14, -- ellipsis
[0x022F0] = 0x15, -- uprightellipsis
[0x022F1] = 0x16, -- downrightellipsis
[0x022D5] = 0x17, -- equalparallel
[0x0225B] = 0x1A, -- stareq
[0x00127] = 0x1B, -- hbar
[0x022F6] = 0x1C, -- barelementof
[0x02209] = 0x1D, -- notelementof
[0x022FD] = 0x1E, -- barcontains
[0x0220C] = 0x1F, -- notcontain
[0x02204] = 0x20, -- nexists
[0x02194] = 0x21, -- leftrightarrow
[0x02195] = 0x22, -- updownarrow
[0x0219E] = 0x23, -- leftleftarrow
[0x0219F] = 0x24, -- upuparrow
[0x021A0] = 0x25, -- rightrightarrow
--~ [0x00026] = 0x26, -- amperand
[0x021A1] = 0x27, -- downdownarrow
[0x021A2] = 0x28, -- leftarrowtail
[0x021A3] = 0x29, -- rightarrowtail
[0x021A4] = 0x2A, -- leftarrowbar
[0x021A6] = 0x2B, -- rightarrowbar
[0x021A5] = 0x2C, -- uparrowbar
--~ [0x02212] = 0x2D, -- minus
--~ [0x0002D] = 0x2D, -- minus
[0x021A7] = 0x2E, -- downarrowbar
[0x021E4] = 0x2F, -- barleftarrow
[0x021E5] = 0x30, -- barrightarrow
[0x021E0] = 0x38, -- dashleftarrow
[0x021E1] = 0x39, -- dashuparrow
[0x021E2] = 0x3A, -- dashrightarrow
[0x021E3] = 0x3B, -- dashdownarrow
[0x021A9] = 0x3C, -- hookleftarrow
--~ [0x0003D] = 0x3D, -- equalto
[0x021AA] = 0x3E, -- hookrightarrow
[0x021AB] = 0x3F, -- looparrowleft
[0x021AC] = 0x40, -- looparrowright
[0x1D538] = 0x41, -- A (blackboard A)
[0x1D539] = 0x42, -- B
[0x02102] = 0x43, -- C
[0x1D53B] = 0x44, -- D
[0x1D53C] = 0x45, -- E
[0x1D53D] = 0x46, -- F
[0x1D53E] = 0x47, -- G
[0x0210D] = 0x48, -- H
[0x1D540] = 0x49, -- I
[0x1D541] = 0x4A, -- J
[0x1D542] = 0x4B, -- K
[0x1D543] = 0x4C, -- L
[0x1D544] = 0x4D, -- M
[0x02115] = 0x4E, -- N
[0x1D546] = 0x4F, -- O
[0x02119] = 0x50, -- P
[0x0211A] = 0x51, -- Q
[0x0211D] = 0x52, -- R
[0x1D54A] = 0x53, -- S
[0x1D54B] = 0x54, -- T
[0x1D54C] = 0x55, -- U
[0x1D54D] = 0x56, -- V
[0x1D54E] = 0x57, -- W
[0x1D54F] = 0x58, -- X
[0x1D550] = 0x59, -- Y
[0x02124] = 0x5A, -- Z (blackboard Z)
[0x0231C] = 0x5B, -- ulcorner
[0x0231D] = 0x5C, -- urcorner
[0x0231E] = 0x5D, -- llcorner
[0x0231F] = 0x5E, -- lrcorner
[0x02225] = 0x5F, -- parallel, Vert, lVert, rVert, arrowvert
[0x021D5] = 0x60, -- Updownarrow
[0x021D4] = 0x61, -- Leftrightarrow
[0x021D6] = 0x62, -- Upleftarrow
[0x021D7] = 0x63, -- Uprightarrow
[0x021D9] = 0x64, -- Downleftarrow
[0x021D5] = 0x65, -- Downrightarrow
[0x021CD] = 0x66, -- nLeftarrow
[0x021CE] = 0x67, -- nLeftrightarrow
[0x021CF] = 0x68, -- nRightarrow
--~ [0x021CE] = 0x69, -- nLeftrightarrow -- what's the difference
between this and 0x0067[0x021CE]
[0x021DA] = 0x6A, -- Lleftarrow
[0x1D55C] = 0x6B, -- k \Bbbk (blackboard k)
[0x021DB] = 0x6C, -- Rrightarrow
[0x021C4] = 0x6D, -- rlarrow
[0x021C6] = 0x6E, -- lrarrow
[0x021C5] = 0x6F, -- udarrow
--~ [0x021C5] = 0x70, -- duarrow
[0x021C7] = 0x71, -- llarrow
[0x021C8] = 0x72, -- uuarrow
[0x021C9] = 0x73, -- rrarrow
[0x021CA] = 0x74, -- ddarrow
[0x021BE] = 0x75, -- rupharpoon
[0x021BF] = 0x76, -- lupharpoon
[0x021C2] = 0x77, -- rdownharpoon
[0x021C3] = 0x78, -- ldownharpoon
[0x021CB] = 0x79, -- lrharpoon
[0x021CC] = 0x7A, -- rlharpoon
[0x021B0] = 0x7B, -- upthenleftarrow
--~ [0x0] = 0x7C, -- part
[0x021B1] = 0x7D, -- upthenrightarrow
--~ [0x0] = 0x7E, -- part
[0x02276] = 0x7F, -- ltgt
[0x021B2] = 0x81, -- downthenleftarrow
[0x021B3] = 0x82, -- downthenrightarrow
[0x02B0E] = 0x83, -- rightthendownarrow
[0x02B10] = 0x84, -- leftthendownarrow
[0x02B0F] = 0x85, --
Re: [NTG-context] MK-II to MK-IV
At Wolfgang Tried \definestructureprefixset[section][section-3][] \setupformulas[numbercolor=blue,numberstyle=bold,prefixset=section] alas it doesn't work. What version of Context are you using ? Thanks ___ 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 ___
Re: [NTG-context] MK-II to MK-IV
Hello,
I checked out context minimals and ran context on your sample file(OS
X Leopard), it worked. The formula is numbered 1.1.
context jh.tex
MTXrun | run 1: luatex
--fmt=/Users/yanger/mystuff/context/tex/texmf-cache/luatex-cache/context/6260f85025788ae8cf4a5735589294e1/formats/cont-en
--lua=/Users/yanger/mystuff/context/tex/texmf-cache/luatex-cache/context/6260f85025788ae8cf4a5735589294e1/formats/cont-en.lui
--backend=pdf ./jh.tex
This is LuaTeX, Version beta-0.50.0-2009122422
\write18 enabled.
(jh.tex
ConTeXt ver: 2010.02.24 11:12 MKIV fmt: 2010.2.24 int: english/english
On Mon, Mar 1, 2010 at 3:39 AM, gummybears oracle...@gmail.com wrote:
Hi,
In reply to Hans, I am using the latest beta (ConTeXt version 2010.02.25
19:46.
mkiv, LuaTeX version 50, LuaTeX revision 0, (LuaTeX date stamp 2009122521))
As Hans requested a small test file,
\setupnumbering[way=bysection] % --- this used to work, but does not
\setupformulas[numbercolor=blue,numberstyle=bold]
\starttext
\chapter{Math formulae numbering}
\section{Does not work}
Numbering formulae by section
\placeformula
\startformula
a^2 + b^2 = c^2
\stopformula
\section{More ...}
\stoptext
Also tried the solution from Contextgarden
(http://wiki.contextgarden.net/Math/Display) by using
\setupnumber[formula][way=bysection] instead of
\setupnumbering[way=bysection]
But alas, this does not work either
On Sun, Feb 28, 2010 at 3:47 AM, gummybears oracle...@gmail.com wrote:
Hi,
A couple of years ago, I decided to switch from LaTex to ConText. Now
I have compiled a lot of documents (Physics syllabi's) which compiles fine
in MK-II.
I thought I would try to make a switch to MK-IV, mainly because I
want to include 3D PRC figures in my documents.
I made some test cases to test MK-IV in order to get a handle on the
differences between MK-II and MK-IV
Some of my observations are
*) Numbered formulas, numbered by section, don't seem to work
*) I am getting a lot of warnings of identifiers, apparently used more
than once, which they are not
LuaTeX warning (ext4): destination with the same identifier
(name{km1_chapter1_sec1}) has been already used, duplicate ignored
Question
Are these observations correct, someone else can confirm them ?
Question
If so, is there a fix, patch, or change in ConText commands/options I am
not aware of ?
TIA
___
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
___
Re: [NTG-context] MK-II to MK-IV
Am 01.03.10 18:17, schrieb gummybears: At Wolfgang Tried \definestructureprefixset[section][section-3][] \setupformulas[numbercolor=blue,numberstyle=bold,prefixset=section] alas it doesn't work. What version of Context are you using ? MTXrun | current version: 2010.02.26 10:57 Wolfgang ___ 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 ___
Re: [NTG-context] MK-II to MK-IV
At saptarshi With MK-II the formula numbers came out (1.1.1), (1.1.2), numbered by section. Chapter 1, section 1, formula 1 - (1.1.1) Chapter 1, section 1, formula 2 - (1.1.2) The above is what I want. Now in MK-IV they come out numbered like Chapter 1, section 1, formula 1 - (1.1) Chapter 1, section 1, formula 2 - (1.2) This is not numbered by section but by chapter, as you confirmed. The problem still persists. On Mon, Mar 1, 2010 at 6:17 PM, gummybears oracle...@gmail.com wrote: At Wolfgang Tried \definestructureprefixset[section][section-3][] \setupformulas[numbercolor=blue,numberstyle=bold,prefixset=section] alas it doesn't work. What version of Context are you using ? Thanks ___ 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 ___
Re: [NTG-context] MK-II to MK-IV
Am 01.03.10 18:32, schrieb gummybears: At saptarshi With MK-II the formula numbers came out (1.1.1), (1.1.2), numbered by section. Chapter 1, section 1, formula 1 - (1.1.1) Chapter 1, section 1, formula 2 - (1.1.2) The above is what I want. Now in MK-IV they come out numbered like Chapter 1, section 1, formula 1 - (1.1) Chapter 1, section 1, formula 2 - (1.2) This is not numbered by section but by chapter, as you confirmed. The problem still persists. \setupformulas[numbercolor=blue,numberstyle=bold,prefixsegments=1:100,way=bysection] Wolfgang ___ 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 ___
Re: [NTG-context] MK-II to MK-IV
Thanks Wolfgang, this worked for me. On Mon, Mar 1, 2010 at 12:47 PM, Wolfgang Schuster schuster.wolfg...@googlemail.com wrote: Am 01.03.10 18:32, schrieb gummybears: At saptarshi With MK-II the formula numbers came out (1.1.1), (1.1.2), numbered by section. Chapter 1, section 1, formula 1 - (1.1.1) Chapter 1, section 1, formula 2 - (1.1.2) The above is what I want. Now in MK-IV they come out numbered like Chapter 1, section 1, formula 1 - (1.1) Chapter 1, section 1, formula 2 - (1.2) This is not numbered by section but by chapter, as you confirmed. The problem still persists. \setupformulas[numbercolor=blue,numberstyle=bold,prefixsegments=1:100,way=bysection] Wolfgang ___ 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 ___
Re: [NTG-context] METAPOST's superellipse with superness0.5 does not give a superellipse
I've come up with a crude function that's doing more like what I want. I
have two problems with it:
1. The most important: I need to differentiate the equations that generate a
superellipse, in order to find the tangent at the defined vertices. I have
failed to do this and so use a crude arbitrary power function.
2. Less important: what is the equivalent in METAFONT of the 'return'
keyword? I just want superellipse() to return the shape, rather than draw
it.
James
def superellipse(expr r,t,l,b,s)=
pair tr, tl, bl, br;
tr = (s[xpart t,xpart r],s[ypart r,ypart t]);
tl = (s[xpart t,xpart l],s[ypart l,ypart t]);
bl = (s[xpart b,xpart l],s[ypart l,ypart b]);
br = (s[xpart b,xpart r],s[ypart r,ypart b]);
numeric theta;
if s 0.5:
% Behave as in the normal superellipse function
theta = 0;
else:
% This is a crude mockup of the kind of function that is required
% to generate shapes with s0.5 (apparently called astroids).
% This satisfies:
%
% s = 0.5, theta = 0.5
% s = 0,theta = 90
%
% But to find the actual function,
% we need to differentiate, at an endpoint,
% the equation that would produce one quadrant of the shape.
theta = 90 - (s*s*s*7.11378661);
fi
fill r{dir(90+theta)} ... tr{t-r} ... {dir(180-theta)}t
t{dir(180+theta)} ... tl{l-t} ... {dir(270-theta)}l
l{dir(270+theta)} ... bl{b-l} ... {dir(-theta)}b
b{dir(theta)} ... br{r-b} ... {dir(90-theta)}r
cycle;
enddef;
beginfig(0);
superellipse(
( 100, 50 ),
( 50, 100 ),
( 0, 50 ),
( 50, 0 ),
0.6
);
endfig;
end;
On Mon, Mar 1, 2010 at 4:20 PM, Rory Molinari quo...@gmail.com wrote:
James's explanation appears to be right.
On p 126 of the METAFONTbook Knuth says that the superness should be
between 0.5 (when you get a diamond) and 1.0 (when you get a square).
Exercise 14.6 asks the reader to Try superellimpse with superness
values less than 0.5 or greater than 1.0; explain why you get weird
shapes in such cases. The answer is There are inflection points,
because there are no bounding triangles for the '...' operations in
the superellipse macro ... unless 0.5 \leq s \leq 1.
Cheers,
Rory
On Mon, Mar 1, 2010 at 8:04 AM, James Fisher jameshfis...@gmail.com
wrote:
I should say that the vertices of the superellipse are calculated
correctly. The problem, it seems, is that for the vertices at right,
top,
left, and bottom, the angles of entry and exit need to be explicitly
defined, rather than just relying on the '...' which coincidentally works
for s=0.5.
I should say at this point that I am no maths whiz. But, sticking with
the
'right ... topright ... top' line, the angle calculation needs to
satisfy,
for the exit angle of the first vertex:
For s=0, angle = 180 degrees (vector to the left)
For s = 0.5, angle = 135 degrees (45 degrees to the top left, producing a
straight line to create the diamond shape)
For s0.5, angle = 90 degrees (vector vertically upwards)
Suffice to say that I don't know how to produce that elegantly.
James
On Mon, Mar 1, 2010 at 3:54 PM, James Fisher jameshfis...@gmail.com
wrote:
Hi again,
Another METAPOST problem. For the sake of curiosity, I've been looking
at
and playing with the superellipse() function in plain METAPOST. This is
all
fine and dandy until I try values of 'superness' less than 0.5, in which
case it generates shapes that are seemingly not superellipses. At
s=0.5,
the function generates a diamond shape -- which, AFAIK, is correct.
However, s0.5, the points of the diamond immediately turn to curves.
(My
knowledge of superellipses here is just from
http://en.wikipedia.org/wiki/Superellipse -- try the image at
http://en.wikipedia.org/wiki/File:Lame_anima.gif to see how I expect
the
shape to change with varying values of superness).
Some code follows -- perhaps someone could run it and tell me if, for
starters, they get the same as me. (See
http://i49.tinypic.com/2ijqatl.jpg
for superellipse() with s=0.3).
Best,
James
% The following is a superellipse function at
http://lists.foundry.supelec.fr/pipermail/metapost-commits/2008-June/000340.html
;
% I think it's the superellipse function in my copy of METAPOST; it at
least has the same behaviour.
% It seems to calculate the vertices correctly, but not the way they
join
(try changing all ... to --).
%
%def superellipse(expr r,t,l,b,s)=
% r ... (s[xpart t,xpart r],s[ypart r,ypart t]){t-r} ...
% t ... (s[xpart t,xpart l],s[ypart l,ypart t]){l-t} ...
% l ... (s[xpart b,xpart l],s[ypart l,ypart b]){b-l} ...
% b ... (s[xpart b,xpart r],s[ypart r,ypart b]){r-b} ... cycle
%enddef;
def supertest expr s =
superellipse(
( 100, 50 ),
( 50, 100 ),
( 0, 50 ),
( 50, 0 ),
s
);
enddef;
% These 0 supernesses are fine, I
Re: [NTG-context] MK-II to MK-IV
Wolfgang, works for me too. Thanks for your time. ___ 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 ___
Re: [NTG-context] METAPOST's superellipse with superness0.5 does not give a superellipse
For 2: I think Metafont makes more sense if you don't think of a macro
as a function that does some work in its own context and returns a
value, but as something that expands textually in place. So there
isn't any concept of return as there aren't separate stack frames to
return from or to.
So you could try something like this (completely untested, and I am a
Metafont beginner. This is from memory, so check the book for the
right syntax, especially for the semicolons.)
def myPath(args) =
begingroup
save tr, tl, bl, br;
pair tr, tl, bl, br;
some equations involving tr, tl, bl, br, and the args;
a path expression;
endgroup;
enddef;
path aPath;
aPath := myPath(args);
fill aPath;
The construction
begingroup
statements;
expression;
endgroup;
lets you do some work in statements, and then give an expression.
The value of the group is the value of the expression. The value
isn't really returned; it just appears wherever a call to myPath
appears. Then the assignment to aPath is expanded by the interpreter
as
aPath := begingroup etc endgroup;
Cheers,
Rory
On Mon, Mar 1, 2010 at 9:57 AM, James Fisher jameshfis...@gmail.com wrote:
I've come up with a crude function that's doing more like what I want. I
have two problems with it:
1. The most important: I need to differentiate the equations that generate a
superellipse, in order to find the tangent at the defined vertices. I have
failed to do this and so use a crude arbitrary power function.
2. Less important: what is the equivalent in METAFONT of the 'return'
keyword? I just want superellipse() to return the shape, rather than draw
it.
James
def superellipse(expr r,t,l,b,s)=
pair tr, tl, bl, br;
tr = (s[xpart t,xpart r],s[ypart r,ypart t]);
tl = (s[xpart t,xpart l],s[ypart l,ypart t]);
bl = (s[xpart b,xpart l],s[ypart l,ypart b]);
br = (s[xpart b,xpart r],s[ypart r,ypart b]);
numeric theta;
if s 0.5:
% Behave as in the normal superellipse function
theta = 0;
else:
% This is a crude mockup of the kind of function that is required
% to generate shapes with s0.5 (apparently called astroids).
% This satisfies:
%
% s = 0.5, theta = 0.5
% s = 0, theta = 90
%
% But to find the actual function,
% we need to differentiate, at an endpoint,
% the equation that would produce one quadrant of the shape.
theta = 90 - (s*s*s*7.11378661);
fi
fill r{dir(90+theta)} ... tr{t-r} ... {dir(180-theta)}t
t{dir(180+theta)} ... tl{l-t} ... {dir(270-theta)}l
l{dir(270+theta)} ... bl{b-l} ... {dir(-theta)}b
b{dir(theta)} ... br{r-b} ... {dir(90-theta)}r
cycle;
enddef;
beginfig(0);
superellipse(
( 100, 50 ),
( 50, 100 ),
( 0, 50 ),
( 50, 0 ),
0.6
);
endfig;
end;
On Mon, Mar 1, 2010 at 4:20 PM, Rory Molinari quo...@gmail.com wrote:
James's explanation appears to be right.
On p 126 of the METAFONTbook Knuth says that the superness should be
between 0.5 (when you get a diamond) and 1.0 (when you get a square).
Exercise 14.6 asks the reader to Try superellimpse with superness
values less than 0.5 or greater than 1.0; explain why you get weird
shapes in such cases. The answer is There are inflection points,
because there are no bounding triangles for the '...' operations in
the superellipse macro ... unless 0.5 \leq s \leq 1.
Cheers,
Rory
On Mon, Mar 1, 2010 at 8:04 AM, James Fisher jameshfis...@gmail.com
wrote:
I should say that the vertices of the superellipse are calculated
correctly. The problem, it seems, is that for the vertices at right,
top,
left, and bottom, the angles of entry and exit need to be explicitly
defined, rather than just relying on the '...' which coincidentally
works
for s=0.5.
I should say at this point that I am no maths whiz. But, sticking with
the
'right ... topright ... top' line, the angle calculation needs to
satisfy,
for the exit angle of the first vertex:
For s=0, angle = 180 degrees (vector to the left)
For s = 0.5, angle = 135 degrees (45 degrees to the top left, producing
a
straight line to create the diamond shape)
For s0.5, angle = 90 degrees (vector vertically upwards)
Suffice to say that I don't know how to produce that elegantly.
James
On Mon, Mar 1, 2010 at 3:54 PM, James Fisher jameshfis...@gmail.com
wrote:
Hi again,
Another METAPOST problem. For the sake of curiosity, I've been looking
at
and playing with the superellipse() function in plain METAPOST. This
is all
fine and dandy until I try values of 'superness' less than 0.5, in
which
case it generates shapes that are seemingly not superellipses. At
s=0.5,
the function generates a diamond shape -- which, AFAIK, is correct.
However, s0.5, the points of the diamond immediately turn to curves.
(My
knowledge of superellipses here is just from
[NTG-context] Dash broken in MKIV
Hi, in MKIV, the long dash (--) seems to be broken. Example: \starttext some -- text \stoptext Outputs with literal -- instead of a longer - as it used to do before. It still worked ~2 weeks ago. I tested it with the minimals (beta) under Linux and Windows. Best Regards, Andreas Schneider. ___ 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 ___
Re: [NTG-context] MK-II to MK-IV
To all interested I found a simpler solution, not knowing how prefixsegments really work, but mainly understand from this example, is \setupformulas[prefixsegments=chapter:section] instead of using \setupformulas[prefixsegments=1:100] Both setups gives the same numbering scheme of the formula numbers. Both setups also don't reset the formula number after a new section, it just keeps numbering the formulas I know I saw a code snippet which does some sort of reset, I think prefixreset or reset, but I cannot find it anymore. ___ 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 ___
Re: [NTG-context] MK-II to MK-IV
Am 01.03.10 22:40, schrieb gummybears: To all interested I found a simpler solution, not knowing how prefixsegments really work, but mainly understand from this example, is \setupformulas[prefixsegments=chapter:section] instead of using \setupformulas[prefixsegments=1:100] interesting Both setups gives the same numbering scheme of the formula numbers. Both setups also don't reset the formula number after a new section, it just keeps numbering the formulas I know I saw a code snippet which does some sort of reset, I think prefixreset or reset, but I cannot find it anymore. way=by... still works, you mean \definestructureresetset but this seems not to be used here Wolfgang ___ 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 ___
Re: [NTG-context] MK-II to MK-IV
On 1-3-2010 22:40, gummybears wrote: To all interested I found a simpler solution, not knowing how prefixsegments really work, but mainly understand from this example, is \setupformulas[prefixsegments=chapter:section] instead of using \setupformulas[prefixsegments=1:100] Both setups gives the same numbering scheme of the formula numbers. Both setups also don't reset the formula number after a new section, it just keeps numbering the formulas I know I saw a code snippet which does some sort of reset, I think prefixreset or reset, but I cannot find it anymore. i hope to stabelize the code this year (i have a few more options in mind) although functionality of mkii is also present in mkiv, some configuration is different (as it is more flexible); also, some obscure features have been removed. we carry a lot more info around (also userdate) and all is accessible during the run (there will be more accessors) the new structure setup is rather undocumented but you can see some in strc-def.mkiv 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 - ___ 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 ___
Re: [NTG-context] MK-II to MK-IV
With the help of Wolfgang (thanks) the solution is (tested) \setupformulas[prefix=yes,prefixsegments=chapter:section,way=bysection] On Mon, Mar 1, 2010 at 10:40 PM, gummybears oracle...@gmail.com wrote: To all interested I found a simpler solution, not knowing how prefixsegments really work, but mainly understand from this example, is \setupformulas[prefixsegments=chapter:section] instead of using \setupformulas[prefixsegments=1:100] Both setups gives the same numbering scheme of the formula numbers. Both setups also don't reset the formula number after a new section, it just keeps numbering the formulas I know I saw a code snippet which does some sort of reset, I think prefixreset or reset, but I cannot find it anymore. ___ 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 ___
Re: [NTG-context] table alignment
Thank you Aditya and Wolfgang, I will try it both: No page breaks possible: \defineframedtext[tablebox][frame=off,width=\hsize,offset=0pt,before =,after=] \starttext vorher \startnarrower text \starttablebox \starttable[s0|l|] \NC table entry \NC\AR \stoptable \stoptablebox \stopnarrower text \startnarrower text \startlinecorrection \dontleavehmode \startTABLE[frame=off,offset=0pt,loffset=0.25ex,roffset=0.25ex] \NC table entry \NC\NR \stopTABLE \stoplinecorrection \stopnarrower text \stoptext Wolfgang ___ 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 ___
Re: [NTG-context] Dash broken in MKIV
On 1-3-2010 20:43, Andreas Schneider wrote: Hi, in MKIV, the long dash (--) seems to be broken. Example: \starttext some -- text \stoptext Outputs with literal -- instead of a longer - as it used to do before. It still worked ~2 weeks ago. I tested it with the minimals (beta) under Linux and Windows. fixed in next beta ... when i moved a function to another file and have forgotten to copy a constant 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 - ___ 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 ___
Re: [NTG-context] Dash broken in MKIV
Hans Hagen wrote: fixed in next beta ... Awesome, fast as usual :-) Thanks a lot! Andreas. ___ 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 ___
Re: [NTG-context] [MkII] Difference in output in minimals versus TeX Live 2009
2010/2/28 Vedran Miletić wrote: 2010/2/26 Mojca Miklavec wrote: I suspect (though I don't really know) that the difference comes from different versions of TeX Gyre. There's a quick experiment you can do: rsync -av \ /usr/local/texlive/2009/texmf-dist/fonts/tfm/public/tex-gyre/ \ /path/to/minimals/tex/texmf/fonts/tfm/public/tex-gyre/ (unless you want to make a backup, but you can quickly revent to the old state anyway by updating the minimals.) The weird thing is that it may be that the minimals contain an older version, but I can fix that soon (I need to double-check why the font didn't get updated automatically since many other fonts do). Mojca Yeah, that fixes it. Can you double-check? The reason was very weird: we wanted to be early adopters, so we were syncing from GUST even before the latest version of fonts became available to CTAN. But once the fonts became available on CTAN, I forgot to switch from the latest zip back to CTAN, so even when a new version came out months later, we kept syncing from that latest version zip. The latest version should be online now. I hope. Mojca ___ 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 ___
