[dev-context] patch: août - aout
Because of http://fr.wikipedia.org/wiki/Rectifications_orthographiques_du_français_en_1990 : --- lang-txt.lua~ 2014-06-04 22:39:45.0 +0200 +++ lang-txt.lua2014-07-22 16:44:02.190189134 +0200 @@ -607,7 +607,7 @@ en=August, es=agosto, fi=elokuu, -fr=août, +fr=aout, gr=Αύγουστος, hr=kolovoza, hu=augusztus, --- mult-def.lua~ 2014-05-23 23:06:28.0 +0200 +++ mult-def.lua2014-07-22 16:43:40.078073408 +0200 @@ -12342,7 +12342,7 @@ [cs]=srpen, [de]=august, [en]=august, - [fr]=août, + [fr]=aout, [it]=agosto, [nl]=augustus, [pe]=آگوست, -- Peter ___ dev-context mailing list dev-context@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] patch: août - aout
On Tue, Jul 22 2014, Alan BRASLAU wrote: Please maintain août and do not cede to any pseudo-reforms, Hi Alan, Why pseudo-reform? or use wikipedia as an authoritative reference... Sorry, this is probably more authoritative: http://www.academie-francaise.fr/sites/academie-francaise.fr/files/rectifications_1990.pdf Anyway, it's not important for me, if you apply the patch or not. (if aout is wrong, then hunspell must be wrong too...) -- Peter ___ dev-context mailing list dev-context@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] patch: août - aout
On Tue, Jul 22 2014, Alan BRASLAU wrote: Which gives acceptable alternative-spellings, and says that the circumflex is not mandatory. It does not suggest that août is incorrect. Furthermore, août remains the reference. All right, thanks for the informations. (if aout is wrong, then hunspell must be wrong too...) Depends on which hunspell dictionary you use... fr_FR ... ;) -- Peter ___ dev-context mailing list dev-context@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Merging font support modules
On Sun, Apr 07 2013, Aditya Mahajan wrote: - URW Garamond support (by Peter Münster; is this still needed? Hi Aditya, I don't think so. It's very old and only for mkii. -- Peter ___ dev-context mailing list dev-context@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Merging font support modules
On Sun, Apr 07 2013, Aditya Mahajan wrote: If the typescripts are needed for MkII, they can still be part of the typescript module by Wolfgang. Of course. But I don't have URW Garamond installed on my system, so I can't test if it still works with latest mkii. (Now I use GaramondPremrPro (OTF) with simplefonts.) -- Peter ___ dev-context mailing list dev-context@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] small patch for grph-inc.lua
On Sat, Jan 05 2013, Hans Hagen wrote: I don't like that figures.current reference there; I don't know any other method... also, the image isn't always scanned yet so the original dimensions are not known. Doesn't matter for this use-case: I just want to make sure, that a new conversion is triggered, when the requested dimensions change. The code a bit below that checks for a time change so that should cover an update of an image and trigger a resample. That's why I want to use your conversion-framework :) Now, if it is the target width/height you want to be part of the name, then it should be some option, because the one thing you don't want is for instance an eps to pdf converter to be applied 10 times if the same image (logo or so) is included 10 times in a different size. All right, I can make a new patch with an option (defaults to no), but please tell me, how I can avoid figures.current? And what's a good name for such an option? -- Peter ___ dev-context mailing list dev-context@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-context
[dev-context] small patch for grph-inc.lua
Hi Hans, Could you please add the following little patch (or something similar) to grph-inc.lua: --- grph-inc.lua~ 2013-01-03 23:32:37.297732874 +0100 +++ grph-inc.lua 2013-01-03 23:42:18.237157620 +0100 @@ -571,6 +571,9 @@ if resolution and resolution ~= then -- the order might change newbase = newbase .. _ .. resolution end +local width = figures.current().request.width or +local height = figures.current().request.height or +newbase = newbase .. _ .. width .. _ .. height -- -- see *, we had: -- The image-downsampling-module¹ would work much better then, because when the name of the file includes the width and the height, there will be a new conversion when the figure dimensions change. ¹ http://modules.contextgarden.net/grph-downsample -- Peter ___ dev-context mailing list dev-context@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] 2 patches for grph-inc
Hello Hans, What do you think about these patches? -- Peter ___ dev-context mailing list dev-context@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] 2 patches for grph-inc
On Fri, Sep 14 2012, Aditya Mahajan wrote: Hans already added a generic function \setemeasure to syst-aux, that can be used here. I've tried, but without success... :( TIA for any further help, -- Peter ___ dev-context mailing list dev-context@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] 2 patches for grph-inc
On Fri, Sep 07 2012, Aditya Mahajan wrote:
+ \edef\current_width{\externalfigureparameter\c!width}%
+ \edef\current_height{\externalfigureparameter\c!height}%
+ \def\nocrap##1{\doifnotemptyvalue{##1}{%
+ \the\dimexpr\csname##1\endcsname\relax}}%
It is better to use a more meaningful name. This can be a general macro that
will be useful outside of the figure inclusion code as well.
Ok. What about \scratch_current_width, \scratch_current_height,
\scratch_nocrap ? Or something similar...
--
Peter
___
dev-context mailing list
dev-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-context
[dev-context] 2 patches for grph-inc
Hi Hans,
Could you please add these 2 patches (or something similar), because the
grph-downsample module¹ would work much better then:
1.) To get the width and the height into the name of the file,
because when the figure dimensions change, there must be a new
conversion:
--8---cut here---start-8---
--- grph-inc.lua~ 2012-06-05 10:37:01.0 +0200
+++ grph-inc.lua2012-07-31 22:40:39.214426838 +0200
@@ -528,6 +528,9 @@
if resolution and resolution ~= then -- the order might
change
newbase = newbase .. _ .. resolution
end
+local width = figures.current().request.width
+local height = figures.current().request.height
+newbase = newbase .. _ .. width .. _ .. height
--
-- see *, we had:
--
--8---cut here---end---8---
2.) To avoid crap in the width and height options:
--8---cut here---start-8---
--- grph-inc.mkiv~ 2012-07-20 23:26:52.0 +0200
+++ grph-inc.mkiv 2012-08-01 00:02:23.851094854 +0200
@@ -293,6 +293,10 @@
%
\the\t_grph_include_local_settings
\dostarttagged\t!image\empty
+ \edef\current_width{\externalfigureparameter\c!width}%
+ \edef\current_height{\externalfigureparameter\c!height}%
+ \def\nocrap##1{\doifnotemptyvalue{##1}{%
+ \the\dimexpr\csname##1\endcsname\relax}}%
\ctxlua{figures.push {
name = \p_grph_include_name,
label = \p_grph_include_label,
@@ -312,8 +316,8 @@
resolution = \externalfigureparameter\c!resolution,
color =
\internalspotcolorparent{\externalfigureparameter\c!color}, % hack is needed
[repeat] = \externalfigureparameter\c!repeat,
-width = \externalfigureparameter\c!width, % can be crap
-height = \externalfigureparameter\c!height, % can be crap
+width = \nocrap{current_width}, % no more crap
+height = \nocrap{current_height}, % no more crap
} }%
\ctxlua{figures.identify()}%
% also mode: checkpresense only
--8---cut here---end---8---
¹ http://modules.contextgarden.net/grph-downsample
TIA,
--
Peter
___
dev-context mailing list
dev-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-context
[dev-context] [NTG-context] upload file on wiki
Hello, The upload seems to be broken: Upload warning The upload directory (public) is not writable by the webserver. -- Peter ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-cont...@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 ___ ___ dev-context mailing list dev-context@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Bug: English versions of manuals mention Dutch command
On Thu, Sep 09 2010, Sietse Brouwer wrote: The English-language versions of ConTeXt, the manual (http://www.pragma-ade.com/general/manuals/cont-eni.pdf) Hello Sietse, This file won't be updated (to be confirmed by Hans perhaps...). Corrections will go directly to the new revision of the manual (work in progress). You can find the links on the main wiki page. Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/ ___ dev-context mailing list dev-context@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Bug: English versions of manuals mention Dutch command
On Sun, Sep 12 2010, Sietse Brouwer wrote: Ah, thank you. I've made a checkout and searched the project for instances of '\inmarge'; there's only one, and that one would end up in the index. Here's the patch: Oh, I'd supposed, that you would rather check the pdf... ;) Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/ ___ dev-context mailing list dev-context@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] context commands in lua-files
On Sun, Jul 18 2010, Hans Hagen wrote:
then they could easily all be merged into a single command table
during loading or even via 'cat'.
I'd rather go for this (see lfg file for examples):
return {
name = placefloat,
version = 1.00,
comment = Insert a floating element.,
}
Hello Hans,
No problem for me, but the suggested cat *.cid all-commands would not work.
and give the files names like placefloat.cid (context interface definition)
and then load them using a lua script (this also permits us to load several
definitions named placefloat e.g. for comparison of versions).
My purpose is to stay in sync (as good as possible) with the latest mkiv but
not to manage versions (I'm lazy, svn is doing that for me in general ;).
But it's no real problem of course, to add some version = xxx, we only need
to remember to increment it sometimes.
Another aspect is shared definitions. Settings like style and align are
often shared so there we need a way to refer to that like
align = interfaces.resolve(align),
I agree.
I'm not sure what the final purpose of this exercise is (intended usage and
so),
My personal motivation is a new version of setup-en.pdf, more verbose
(detailed description of all options), complete (even for low-level commands,
but no obsolete commands), and with some additional features (categories,
index, cross-references).
See also:
http://archive.contextgarden.net/message/20100508.204345.b5003312.en.html
But it's even better, if this exercise can serve also other goals
(for example syntax-checking, replacing cont-en.xml,
replacing texshow-wiki etc.).
but if it's to be integrated (or loaded in context) it has to fit in
the general way such data is stored.
My idea was to put these command-descriptions on an svn-server, for example
here: http://foundry.supelec.fr/svn/contextman/context-commands
So, that all can contribute.
If the files were in the context-distribution, I don't know, how others than
you can contribute.
So, given this thread .. can we summarize the state of a couple of
commands? Say:
- setupframed (inherited)
- framed (inherits, resolving)
- setupheadertexts (several arg configurations)
- externalfigure (several arg configurations)
- itemize (start command)
It's here: http://pmrb.free.fr/tmp/context-commands/
Cheers, Peter
--
Contact information: http://pmrb.free.fr/contact/
___
dev-context mailing list
dev-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] context commands in lua-files
On Sun, Jul 18 2010, Taco Hoekwater wrote:
If you start your files like this:
command = command or {}
command['placefloat'] = {
comment = Insert a floating element.,
...
}
then they could easily all be merged into a single command table
during loading or even via 'cat'.
Like Mojca says, it is better not to be dependent on the file name, and
also it is more efficient to have a single lua file than 500-600
separate ones. There is no need to combine them immediately, but if
this goes into the distro at some point then a single large file is
definitely better than lots of smaller ones.
Ok, I agree. The very strong reason for one file per command is the better
comfort when editing the files.
And the big file for the distribution can be generated with
cat * commands.lua
Peter
--
Contact information: http://pmrb.free.fr/contact/
___
dev-context mailing list
dev-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] context commands in lua-files
On Sat, Jul 17 2010, Mojca Miklavec wrote:
A few random comments from externalfigure:
- Despite the fact that the command name is known from filename,
wouldn't it be nice to have externalfigure string defined somewhere?
Ok, see response to Taco.
- It is not really needed, but it helps when cross-referencing: I
would nevertheless leave the [1] = {...}, [2] = {...} for arguments
- The following:
settings = {
inherit = useexternalfigure,
-- n = 3 not needed, since one command has only one settings-option
},
is a bit weird to me. Why not putting the inherit already under
arguments above? And yes, you probably do need to tell from which
argument of \useexternalfigure you want to inherit the settings.
From my very small ConTeXt experience, I made some assumptions:
- one command has no more than one settings-option (key-val-pairs)
- one command has no more than one keywords-option
If this is true, then there is no problem with cross-referencing.
The n = X would be even difficult, when there a variants: imagine,
\useexternalfigure can have settings at n = 2 or n = 4 and so on.
And I like the separate settings-table, because it can be very big and
would clutter the arguments table.
If my assumptions are wrong, then there will be more problems:
perhaps the settings must go into the arguments table or we need a lot of
numbering (n = X here and there).
- If all the three arguments are optional, it's a bit difficult to
tell what combination of arguments is allowed, so it might make sense
to be a bit more verbose in that (to tell somehow that for example
only 123 and 23 and 3 is allowed, but not 13 for example), but this is
not too important.
I think, there has to be some introduction chapter for the user with the
general rules in ConTeXt-commands. I suppose these rules:
- when a command has an optional keyword-option and an optional
settings-option and you use only one of them, you don't need a
placeholder (empty bracket pair)
example: \setupitemize[packed] or \setupitemize[start=5]
(context is intelligent here)
- context cannot distinguish between label and keyword, so if you want to
use a label in \placefloat, you must add a placeholder for the keyword
Hans can tell us perhaps more about these rules...
Furthermore, we can add in this introduction some notes about spaces:
- space is allowed between 2 bracket options
- space is allowed after a comma
- space is not allowed before and after the =
- space is gobbled after ] if not all optional arguments are used
Cheers, Peter
--
Contact information: http://pmrb.free.fr/contact/
___
dev-context mailing list
dev-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] context commands in lua-files
On Sun, Jul 18 2010, Taco Hoekwater wrote:
arguments = {
[label_arg] = {
type = label,
},
[filename_arg] = {
type = file,
},
[settings_arg] = {
type = settings,
comment = short comment for this option,
description = long description for this option,
inherit = { useexternalfigure, 'settings_arg' }
},
[parent_arg] = {
type = parent,
comment = short comment for this option,
description = long description for this option
},
},
variants = { -- just an example
{ filename_arg },
{ label_arg, filename_arg },
{ label_arg, filename_arg, settings_arg },
{ filename_arg, parent_arg },
}
},
but I am not sure this is really better ?
Seems to be ok for \externalfigure but not for \setupheadertexts...
Peter
--
Contact information: http://pmrb.free.fr/contact/
___
dev-context mailing list
dev-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] context commands in lua-files
On Sun, Jul 18 2010, Peter Münster wrote: - If all the three arguments are optional, it's a bit difficult to tell what combination of arguments is allowed, so it might make sense to be a bit more verbose in that (to tell somehow that for example only 123 and 23 and 3 is allowed, but not 13 for example), but this is not too important. I think, there has to be some introduction chapter for the user with the general rules in ConTeXt-commands. I suppose these rules: [...] And when a command does not follow these rules (perhaps \externalfigure is such a case), then there must be some notes about this in the description. Peter -- Contact information: http://pmrb.free.fr/contact/ ___ dev-context mailing list dev-context@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] context commands in lua-files
On Sun, Jul 18 2010, Taco Hoekwater wrote:
variants = { -- just an example
{ filename_arg },
{ label_arg, filename_arg },
{ label_arg, filename_arg, settings_arg },
{ filename_arg, parent_arg },
Now I see the big benefit!
Instead of having 2 concepts (optional arguments and variants), we keep
only the concept of variants!
Very good!
Peter
--
Contact information: http://pmrb.free.fr/contact/
___
dev-context mailing list
dev-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] context commands in lua-files
On Sat, Jul 17 2010, luigi scarso wrote:
Why don't put them into a table as is in
http://www.lua.org/pil/10.1.html
For exampl e placefloat.lua should be
placefloat ={
props = {
[...]
Because I like to avoid redundancy.
It's easy to do things like this automatically:
local placefloat = {}
setfenv(0, placefloat)
dofile(placefloat.lua)
setfenv(0, _G)
print(placefloat.props.fixpart)
Or like this:
placefloat.lua:
entry = { -- or command
props = ...,
args = ...,
...
}
And then:
local commands = {}
dofile(placefloat.lua)
commands.placefloat = entry (or command)
print(placefloat.props.fixpart)
Cheers, Peter
--
Contact information: http://pmrb.free.fr/contact/
___
dev-context mailing list
dev-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] context commands in lua-files
On Sat, Jul 17 2010, luigi scarso wrote: Why don't put them into a table as is in http://www.lua.org/pil/10.1.html Ok, now one file defines exactly one command table. I added also other minor enhancements. Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/ ___ dev-context mailing list dev-context@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] cont-en.xml
On Fri, Jul 02 2010, Wolfgang Schuster wrote: The idea is not bad but who is going to do this? Hans implemented in mkiv the function to check assignments list of valid keys but this function isn't used because nobody writes the necessary lists which contexts requires to do these checks and the same will happen with the system you suggest. That's why I'm eventually going to do this: http://archive.contextgarden.net/message/20100508.204345.b5003312.en.html Perhaps using tex-files like this: http://pmrb.free.fr/tmp/context-commands/ Perhaps in this directory: http://foundry.supelec.fr/svn/contextman/context-commands So that everybody can contribute via svn. But before doing that effort, I still need a bit more feedback... Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/ ___ dev-context mailing list dev-context@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] cont-en.xml
On Wed, Jun 16 2010, Wolfgang Schuster wrote: i plan to update cont-en.xml with changes in mkiv (new keys and commands) Hello Wolfgang, Since Hans said documentation about tex can best be done in tex, I've put my ideas into some files here: http://pmrb.free.fr/tmp/context-commands/ What do you think about that? Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/ ___ dev-context mailing list dev-context@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] audit of commands
On Tue, May 11 2010, Taco Hoekwater wrote: It also makes editing the wiki much easier (using also wiki tables instead of HTML tables etc.) This is definitely true, but for the export there is a simple solution: export as xml, feed the output through Tidy, then process with mkiv's native xml support. Hello, It's not so funny to deal with the actual structure and make conversion tools like this: color=red - optional parameter, strong.../strong - default value Also, the editing performance is much higher when using a good editor instead of html-wiki-forms. In order to be motivated to spend time on this project, I - don't want to get blocked by limits (e.g. wiki-limitations), that I cannot control - want to have a well designed structure: ergonomic for editing and beautiful (as Hans said: TeX seems to be a good choice) - want to use my favorite editor for writing the command descriptions At the moment, I don't really understand how to carry that out using the wiki... :( Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/ ___ dev-context mailing list dev-context@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] audit of commands
On Sun, May 09 2010, Hans Hagen wrote:
So, how about more extensive info. As each command has a unique reference,
the best approach is to have a separate file for each such entry. I suppose
that this can be generated from the wiki.
Hello Hans,
Yes, I also like one file per command, it's easier to manage.
From that it's possible to generate something big (although big pdf's are
not that much fun) or generate command specific files that are crosslinked
to the main setup file.
For looking up something, I often open big pdf-files ( 1000 pages), and
the size doesn't matter. But for printing it, I agree. If someone really
wants to print it on A4, the font size must be small and it must be
2-column layout.
I imagine the following steps:
1. decision how to structure the commands (lua or xml or ...)
the xml is handy for manipulations but documentation about tex can best be
done in tex (verbatim can get quite messy in xml)
Thanks for the advice. This is good, because I don't have any experience
with xml.
3. implementation of \showsetup (currently broken anyway)
hm, in what sense broken?
No output:
\usemodule[set-11] \loadsetups % from contextref-env.tex (context-manual)
\starttext
\showsetup{startproject} % from co-documents.tex (context-manual)
\stoptext
ambituous -)
Yes, it'll take a long time (I can spend only 2-3 hours per week...).
So what about:
- a new directory
http://foundry.supelec.fr/svn/contextman/context-commands;
- one tex-file per command
?
If you agree, I just start.
Cheers, Peter
--
Contact information: http://pmrb.free.fr/contact/
___
dev-context mailing list
dev-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] audit of commands
On Thu, May 06 2010, Idris Samawi Hamid ادريس سماوي حامد wrote: I'm interested in an audit of all current mid-to-high-level mkiv commands, including experimental or undocumented ones. I'm trying to come up with, as much as possible, a set of context commands which is mutually exclusive jointly exhaustive. Hello, I would like to contribute to a very similar project: a new version of setup-en.pdf, more verbose (detailed description of all options), complete (even for low-level commands, but like you no obsolete commands), and with some additional features (categories, index, cross-references). There is also the new command reference on the wiki, but it's not enough tagged. Here my questions: - How could all these efforts be shared in the most efficient way? - Are others already working for the above project? - Is the structure of cont-en.xml already the good choice and it only needs some extensions for additional features, or would it be as good to use lua-tables (one lua-file per command for example)? I imagine the following steps: 1. decision how to structure the commands (lua or xml or ...) 2. script for producing setup-en.pdf (perhaps Hans can provide his current converter?) 3. implementation of \showsetup (currently broken anyway) 4. filling in the structure with all available information at the moment (last cont-en.xml, wiki) 5. putting nightly built setup-en.pdf on-line 6. filling the structure with all command descriptions Then continuously: 7. updating command descriptions at each update on the wiki 8. updating command descriptions at each new context release 9. updating command descriptions whenever something seems not clear enough (questions on mailing list) Please send me your comments! Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/ ___ dev-context mailing list dev-context@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-context
