Re: [NTG-context] presentation (simple-slides?) master-like feature?
On Wed, Oct 28, 2009 at 2:40 PM, Aditya Mahajan adit...@umich.edu wrote:
On Wed, 28 Oct 2009, Thomas A. Schmitz wrote:
Bruce,
very briefly: I'm very very short on time this week, so won't be able to
look into this until middle of next week, but I just wanted to let you know
that I find your idea great. I had been thinking of adding an xml template
for simple presentations. your html-based stuff looks gorgeous, so I would
like to know more about it. And let us know what exactly it is that you're
missing in simple-slides. In theory, titles are typeset in layers, so
everything should be there.
I also like this idea. In fact, it will not be too difficult to map these to
simple-slides. Basically
li class=slide title
h1Test Slide Show/h1
/li
should be translated to
\setupTitle[title=Test Slide Show,author=,date=]
\placeTitle
Well, except that I want the option to have this sort of rendering
elsewhere in the presentation. I see you address that in a followup;
would love to see you add that macro.
BTW, I'm an academic as well, so using this for both teaching and
research presentations (my immediate concern here; have a talk coming
up in a few weeks I'd like to try this on).
and
li class=slide
h1Hello/h1
ul
lione/li
litwo/li
/ul
/li
should be translated to
\SlideTitle{Hello}
\startitemize
\item one
\item two
\stopitemize
we currently do not have any specific environment for blockquote (but Thomas
and I have discussed adding something similar). The vanilla ConTeXt
equivalent \startblockquote ... \stopblockquote doesn't do anything fancy.
Finally,
li class=slide imgbig
h1Container Ships/h1
img src=filename.jpg /
/li
should be translated to
\IncludePicture[horizontal][filename.jpg]{Container Ships}
I do not know what is the best way to do these translations. ConTeXt can
also handle XML files, so it is just a matter of writing the translation
rules in ConTeXt. Or, if you prefer, you can write an XSLT transformation.
Yeah, using XSLT is pretty straightforward for this.
Bruce
___
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] Seeking a Deeper ConTeXt: Questions f or Initializing
Hans Hagen pragma at wxs.nl writes: ... in which case it keeps the input in xml and converts to other formats (coule be tex in the case of rendering print). As Hans says, if you're interesting in integrating XML and RDF in source documents, you need to think of ConTeXt as a lower-level output format; not the other way around. Depending on your needs, I'd consider two options for the source format: XHTML + RDFa, and OpenDocument 1.2 (which will include RDF and RDFa support; likely to be implemented first in OpenOffice 3.2). DocBook is an option too, but does not AFAIK support RDFa. In any case, I'd worry less about the technology, and more about what you need from it. That will make it easier to figure out which approach is best. Bruce ___ 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 : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] Seeking a Deeper ConTeXt: Questions for Initializing
John Haltiwanger john.haltiwanger at gmail.com writes: [...] Markdown with RDFa on the side will suit quite nicely, thanks to pandoc. Actually, you can embed the RDFa within the markdown files if you like. div property=x:section # Introduction Test. /div Pandoc will just pass it on to the output XHTML (though throw it out for the context). But it's admittedly a little awkward to have to wrap the markdown with XHTML every time to want to add a triple. Bruce ___ 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 : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] bibmodule (again)
Taco Hoekwater taco at elvenkind.com writes: The new structure and referencing code is totally different from the old code and I understand less than half of it. What's worse: I seem to be really bad at explaining to Hans all the things that should happen wrt. references in the bib module. :-) FWIW, Frank Bennett has completely written the Zotero Javascript CSL engine to be faster and easier to maintain and extend. It's also now independently hosted and developed. http://bitbucket.org/fbennett/citeproc-js Bruce ___ 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 : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] New bib module
Taco Hoekwater taco at elvenkind.com writes: Bruce D'Arcus wrote: Wolfgang Schuster schuster.wolfgang at googlemail.com writes: Am 31.03.2009 um 09:27 schrieb Taco Hoekwater: Will this new module also provide BibX support? Perhaps ;) On the input side, the new module will load bibliographies from disk into an internal XML structure and then use lpath queries to fetch bibliographic data. It will use separate loaders to do so, so in the end, anything can be plugged in as long as it can be converted to the internal structure. Why not just a lua table to save the data? Yes, I was wondering the same thing. This is typically how the various CSL implementations work; parse the input data (XML, RDF, BibTeX, etc.) into some internal structure. I was't clear enough. internal XML structure actually is a lua table structure. It just follows a bunch of special rules that make lpath queries work. So it's a native Lua mapping of an XML model? E.g. something like, say, element tree provides for Python? Does that suggest that the input data is always XML? Bruce PS - Frank Bennett has been doing a lot of promising work on a rewrite of Zotero's javscript-based CSL processor: http://xbiblio.svn.sourceforge.net/viewvc/xbiblio/citeproc-js/trunk/. ___ 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 : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] New bib module
Wolfgang Schuster schuster.wolfgang at googlemail.com writes: Am 31.03.2009 um 09:27 schrieb Taco Hoekwater: Will this new module also provide BibX support? Perhaps ;) On the input side, the new module will load bibliographies from disk into an internal XML structure and then use lpath queries to fetch bibliographic data. It will use separate loaders to do so, so in the end, anything can be plugged in as long as it can be converted to the internal structure. Why not just a lua table to save the data? Yes, I was wondering the same thing. This is typically how the various CSL implementations work; parse the input data (XML, RDF, BibTeX, etc.) into some internal structure. Bruce ___ 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 : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] typescript repository
Wolfgang Schuster schuster.wolfgang at googlemail.com writes: Am 23.03.2009 um 22:51 schrieb Mohamed Bana: I personally would like see a professionally done typescript for Minion and Warnock Pro with Myriad and Cronos Pro. I posted mine a while ago, but I got no feed back. Because people need the fonts to make a test and Adobes *free* Minion/ Myriad come only with four styles (no opticals). You could also opticals with MkIV but it requires more work - http://wiki.contextgarden.net/Optical_Size I think: a) dealing with typescripts in ConteXt is a far bigger problem than it should be b) that it's fantastically good idea to have a repository of typescripts to address this problem c) that there's no reason at all to make a distinction between free and professional fonts in such a repository As for how to do it, I could imagine using the wiki. But I could also imagine some other approach, like someone starting a project on GitHub or something similar. Bruce ___ 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 : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] Bibliographic Databases
Taco Hoekwater taco at elvenkind.com writes: Hi, Andreas Wagner wrote: Just out of curiosity: What are your reasons for preferring this over TEI: MODS was a logical choice mostly my background (scientific publishers = MARC databases = MODS), and that BruceD'Arcus liked it. Btw, his blog is full of bibliographic articles, if you are interested: http://community.muohio.edu/blogs/darcusb/ (but it looks like he has switched over to RDF now) Yes, but ... I am not really set to any particular xml format, and there are more mainstream choices (risx comes to mind). ... I'd say for the design of something like mbib v2 I'd advocate an internal model that abstracts away from any particular more concrete representation. So think in terms of maybe a standard input driver, but leave room for easy development of others. There's some work going on a Python version of my citeproc effort, for example, and he's planning input drivers for MODS, RDF, BibTeX, etc. http://xbiblio.svn.sourceforge.net/viewvc/xbiblio/citeproc-py/citeproc/ This makes is easy for someone to write another input driver for some SQL model. But the few times I've had to work with TEI stuff I found that you can easily get much more than you bargained for. Bibliographic data is not easy on its own, and a format that allows (almost promotes) extra tags to be embedded also is not helping at all. Look at this: http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-author.html Just the 'core' module is already pretty complex, but 'namesdates' and 'linking' are definately also required for a useful bibliographic database. The nice, consise examples in the TEI docs are misleading because authorLucy Allen Paton/author is useless, more specifics are needed. We need at least this: author persName forenameLucy/forename forenameAllen/forename surnamePaton/surname /persName /author But with the use of persName, there are suddenly a gazillion ways an author can encode the same name (and it does not preclude any of the other ways to encode a name). http://www.tei-c.org/release/doc/tei-p5-doc/html/ND.html#NDPER Etc. etc. Imagine having to support that in a simple context module. In the XML citation style language I designed [1] (which *could* serve as the basis for that internal model I mention above), there's an implicit notion that any name can have both a sort form and a display form, and that they may (but in contexts like Eastern Europe or Asia often don't) differ. This makes things in many ways both simpler, and more general (works for organizations, as well as is more international-friendly than traditional first/last). You just handle the details you note above in the input drive code. Bruce [1] http://xbiblio.svn.sourceforge.net/viewvc/xbiblio/csl/schema/trunk/csl.rnc?view=markup ___ 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 : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] bib amd mods
Hi Hans, Hans Hagen pragma at wxs.nl writes: I wonder, is there any interest in the following: - support for http://www.loc.gov/standards/mods/ as basic bibl format I think Ulf's conclusions are right. MODS is expressive, which is why I was originally attracted to it, but it's also more complex than it needs to be for this sort of use case. The big question becomes, if not MODS, then what? As Ulf pointed out, my solution -- and the one I will be advocating for OpenDoucment (I am on the TC) -- is to use a particular RDF serialization. Indeed, I have a draft RELAX NG schema for it, and my formatting system (citeproc) now works with it quite well. Microsoft, incidentally, is implementing pretty good bib support (that looks suspiciously like what I've been advocating for OpenOffice!), which I've blogged about extensively. Their XML format is not bad, though it is totally flat, which means it won't be as flexible as MODS or RDF. More here: http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2006/06/16/flat-vs-relational - provide converters from marcs and bibtex to mods - layer the bib module on top of that Curious question: would you be writing it in Lua (closer to the pdftex level), or go more high-level (as now)? If so, who'd like to join/volunteer for subtasks I can certainly help with advice and design, particularly if you want to use CSL to configure the output. I've made some changes to it (again) recently, but think I'm zeroing in on freezing it. The more feedback I get, the easier it'll be to do that. Incidentally, I'm considering the possibility of submitting CSL to OASIS for standardization, though only if I can get some industry players involved. Bruce ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] crossref in bibtex
Taco Hoekwater taco at elvenkind.com writes: [.. snip ...] The next major release of the module (but don't expect a release anywhere this year) will indeed support MODS through citeproc: http://xbiblio.sourceforge.net/citeproc/ As the author of citeproc (hi Taco!), let me just update people on recent developments there, which are currently in the project subversion repository*, but not yet officially released. First, I have switched to using a particular RDF/XML as the internal representation, and also therefore the primary input format. I will likely be adding back a MODS input driver when I get a chance, but it's no longer the focus. I will also be releasing a schema for this RDF representation for people that need it. The primary reason for this change is that in comparison to MODS, RDF has a consistent model that makes it easier to model reference metadata. It's also fundamentally a relational model, and so easier to integrate with relational databases where needed. Also, I am working with the OpenDocument Technical Committee on a plan to add extensible metadata support using this RDF-based approach, so we hope to adopt this in OpenOffice as well (I am co-project lead for the OOo bib project). Second, I have started porting CiteProc to Ruby (and put a citeproc-py directory in the repo for those python coders that might want to contribute), which might integrate better with ConTeXt. (I suppose Lua might also be an option given the integration with pdftex?) In any case, this will take me a bit of time as a) I don't have much of it, and b) my coding skills aren't that great. But the actual formatting code (Ruby, XSLT, etc.) is to my mind less important than the logic as embedded in the XML citation style language I wrote to configure the formatting. http://xbiblio.sourceforge.net/csl/ Bruce * http://svn.sourceforge.net/viewcvs.cgi/xbiblio/ ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
[NTG-context] Re: mag-0008
On Dec 15, 2004, at 12:16 PM, Hans Hagen wrote: that was from the time that i played with schema's, nowadays i prefer relax ng Indeed! It may be worth noting that the next generation versions of both DocBook and TEI: - are developed in RELAX NG - are namespaced - are designed for customizability, including mixing-and-matching definitions across the schemas Bruce ___ ntg-context mailing list [EMAIL PROTECTED] http://www.ntg.nl/mailman/listinfo/ntg-context
[NTG-context] Re: mag-0008 (was: XML formulas)
On Dec 13, 2004, at 1:02 PM, Adam Lindsay wrote: What I propose is clearly a debatable XML-design issue, but it seemed strange that fx:definelayout and fx:p were put into the same namespace. Why do the formatting definitions share the same (theoretical) schema as markup? Your documents keep these categories separate, as one would expect. Why not encourage people to put them in separate files, as with normal ConTeXt workflows? The designer and author are more clearly divorced when you don't assume an XSLT-centric flow, right? FWIW, I'm currently working on a comprehensive XSLT-based solution for bibliographic formatting (think bibtex for xml, only better). In that, I'm working across multiple namespaces: 1) document (docbook ng) 2) bibliographic data (mods) 3) a citation formatting language (homegrown; again, in its own namespace) 4) output (xhtml, for example) I agree with the notion that, in principle, semantic document markup should be in a separate namespace from the formatting language. BTW, Hans, I've yet to see the ContML schema. Care to post it somewhere? Also, FYI, I and an engineer at Sun have some up with a small citation schema designed for embedding in other XML dialects. It has been approved for OpenOffice. http://www.users.muohio.edu/darcusb/files/citation-schema.tar.gz It's more for GUI apps (it's rather verbose), but could still be useful in other contexts. Bruce ___ ntg-context mailing list [EMAIL PROTECTED] http://www.ntg.nl/mailman/listinfo/ntg-context
[NTG-context] Re: ConTeXt Switcher?
someone (not sure who) said: I know XML source should work, but at least for me, creating XML source is unproductive. I work with a text editor and find writing this: ``Hello world,'' says HAL. much more productive than writing this: p#8220;Hello world#8221;/p, says HAL. Maybe I'm missing something, but for writing, XML's markup requirements -- which are invisible to field-based data entry screen -- are way too intense for hand-editing. TeX source is much less verbose. It is easier to create, proof (both visually and audibly), spell check troubleshoot, etc. I have not seen an editor capable of doing XML source in a productive manner, like (La)TeX with text editor. You're missing something. For one, your above example would be: pqHello world/q, says HAL./p Second, try something like nXML mode for emacs, or the XML plug-in for jEdit. Real-time markup validation, tag-completion, spell-checking, etc. Finally, you're missing the biggest point of all: XML is about reuse. You cleanly separate markup from presentation so that -- among other things -- you can trivially transform that to different output. Bruce ___ ntg-context mailing list [EMAIL PROTECTED] http://www.ntg.nl/mailman/listinfo/ntg-context
