Re: [NTG-context] presentation (simple-slides?) master-like feature?

[Bruce D'Arcus]

On Wed, Oct 28, 2009 at 2:40 PM, Aditya Mahajan  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
>
>      
>        Test Slide Show
>      
>
> 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
>     
>        Hello
>        
>          one
>          two
>        
>      
>
> 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,
>        
>           Container Ships
>           
>        
>
> 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 for Initializing

[Bruce D'Arcus]

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



# Introduction

Test.


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] Seeking a Deeper ConTeXt: Questions f or Initializing

[Bruce D'Arcus]

Hans Hagen  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] bibmodule (again)

[Bruce D'Arcus]

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



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

[Bruce D'Arcus]

Taco Hoekwater  elvenkind.com> writes:

> Bruce D'Arcus wrote:
> > Wolfgang Schuster  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

[Bruce D'Arcus]

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

[Bruce D'Arcus]

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

[Bruce D'Arcus]

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



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
> 
>Lucy Allen Paton
> 
> is useless, more specifics are needed. We need at least this:
> 
>
>  
>Lucy
>Allen
>Paton
>  
>
> 
> But with the use of , 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]


___
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

[Bruce D'Arcus]

Ulf Martin  web.de> writes:

> I think the crucial point for any TeX community is the ability to use 
> the rather huge amount of BibTeX legacy DBs.
> 
> How about the state of CSL (or RDF) to BibTeX converters?

I don't care about BibTeX myself, so such things aren't my focus.
However, I think a good XML/RDF data format makes it pretty easy
to downconvert to formats like BibTeX. Indeed, it took me 30 minutes 
or so to write a decent XSLT to convert MODS to the RDF/XML I'm 
using. That was only targeted at book descriptions, so it would take 
more time for a comprehensive version, but it shows it's not hard. 

The hard part, in fact, is the logic for conversion, and most of that 
is clearly documented in the bibutils source code.
 
> bibutils uses MODS as its native intermediate format and converts from 
> and to BibTeX (not always 100% correct, though).

Correct, though it's actually more complicated than that. It uses 
a C-based internal format that is based on lessons from MODS and from 
converting the other legacy formats.

> Summary
> ---
> 
> So, at present we already have:
> 
> (1)  MODS <-(bibutils)-> BibTeX -(bibmod)-> ConTeXt
> 
> For an XML-based format in a ConTeXt context we would like to have:
> 
> (2)  BibTeX <-(a)-> XML -(b)-> ConTeXt

*We* wouldn't include me. I deal much more with RIS or Endnote 
formats than I do with BibTeX. But I don't use ConTeXt for authoring 
either ;-)

> using the rather nice XML processing capabilities of ConTeXt for
> step (b).
> 
> Now, there is an XML markup for BibTeX: BibTeXML
> http://bibtexml.sourceforge.net/
> This isn't too bad, in my experience (it is, at least, lossless, 
> contrary to bibutils). Thus
> 
> (3)  BibTeX <-(bibtexml)-> BibTeXML -(b')-> ConTeXt
> 
> would be an instance of (2).

Yes, but BibTeXML still has all the problems of the BibTeX model.
 
> CSL could use XSL transformer:
> 
> (4)  BibTeXML <-(XSLT)-> CSL -(b")-> ConTeXt

All CSL is is a language-angostic XML config language. You could 
write a CSL engine in whatever language you want: TeX, Lua, Perl, 
Ruby, C. *I* wrote mine in XSLT 2.0, but that's mostly because of 
limited skills with other langauges.

I also designed citeproc, BTW, to have both an input and output 
driver system. So while I use an RDF/XML representation 
internally, it wouldn't be too hard to write other inout drivers. 
A next-generation mbib module probably ought to do the same, so 
that while it might have a richer core format, it could still be 
fed BibTeX, or even MODS.

Bruce



___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

Re: [NTG-context] bib amd mods

[Bruce D'Arcus]

Hi Hans,

Hans Hagen  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:



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

[Bruce D'Arcus]

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



Bruce

* 

___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

[NTG-context] Re: mag-0008

[Bruce D'Arcus]

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 & s)

[Bruce D'Arcus]

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?

[Bruce D'Arcus]

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:
> 
> “Hello world”, 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:

Hello world, says HAL.

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

[NTG-context] Re: Expert fonts

[Bruce D'Arcus]

In <[EMAIL PROTECTED]> Thomas A.Schmitz  
wrote:
> Expert fonts have been mentioned on this list several times, but I'd 
> like to know if anybody could point me to e tutorial/example how to 
> make them work in Context. The background of my question: on my Mac, I 
> have a nice-looking truetype font "HoeflerText" which has most glyphs 
> of an expert font (oldstyle numbers, small caps, additional ligatures 
> etc.), and I wonder if it would be possible to split it up into 
> several  type 1 fonts (via pfaedit) and make them work like an expert 
> family.  Any suggestions about this? Thanks! Thomas

I don't recommend converting to type 1.  Better to just use ttf2tex with 
its expert switch.  That'll get you access to all the standard expert 
glyphs, though you'd need to write the typescripts.  It'd be nice to see 
someone extend ttf2tex to do this too though (it already creates all the 
files for LaTeX).

Bruce

___
ntg-context mailing list
[EMAIL PROTECTED]
http://www.ntg.nl/mailman/listinfo/ntg-context