My suggestion for asciidoc is to use Mathjax. There are straigfordward instructions at this thread:
http://groups.google.com/group/asciidoc/browse_thread/thread/4a80346a5f4bb728 In particular read the answer from David E. Miller on 29th of June. Formulas are of excellen quality, they are rendered they are not bitmaps!!!, so the y are scalable... Have a nice day, Javier On Mon, Sep 12, 2011 at 10:03 AM, John Prentice <j...@castlewd.freeserve.co.uk> wrote: > ----- Original Message ----- > From: "Chris Morley" <chrisinnana...@hotmail.com> > > <snip> >> >> And really I think the HAL file should be made smaller and be about basic >> use of >> HAL and a few of it's tricks for diagnosing problems. >> >> Chris M >> The rest of HAL belongs in the integrators manual as HAL is mostly what an >> integrator has to deal with. >> > As a relatively new "user" I endorse those suggestions. I would look to the > Integrator's Manual (System Integrator's manual might be a better title for > this) for definitions of components and the running of .hal files from the > configuration etc. The HAL manual would give the philosophy, the syntax and > semantics of commands and the documentation of the tools ('meter, 'scope and > comp). > > IMO some revision of the core HAL text is needed. > > (a) The introduction still has overtones of the discussions justifying > having a HAL. > > (b) There is a lot on the syntax of names but no reference material on using > them. For example I have found defining a net on one line to be the most > readable way of wiring a few pins > > net foo-enable.0 panel.0.enable => drive.0.enable drive.1.enable > drive.2.enable > > This possibility is not documented in the 2.4 manual as far as I know. > > (c) I think there should be some guidance for component writers on the use > of parameters versus pins. For example the gains in PID are parameters but > they are defined in such a way that one cannot connect them to "tuning > scale" controls on a VCP. In my ignorance I do not actually see the need > for the two concepts - but that is another matter. > > John Prentice > > > ------------------------------------------------------------------------------ > Doing More with Less: The Next Generation Virtual Desktop > What are the key obstacles that have prevented many mid-market businesses > from deploying virtual desktops? How do next-generation virtual desktops > provide companies an easier-to-deploy, easier-to-manage and more affordable > virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > > ------------------------------------------------------------------------------ Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
