No, it's just the constant value given to the new XHTML output
filters, which are combinations of our FMT_WEBIF and FMT_HTMLHREF
filters.
--Greg
On Wed, Jun 29, 2011 at 10:29 AM, David Haslam wrote:
> Is FMT_XHTML related in any way to what Jim Allbright is working on at
> Wycliffe?
>
> See htt
Is FMT_XHTML related in any way to what Jim Allbright is working on at
Wycliffe?
See http://ws.ibs.org/niv/samples/ScriptureXHTML.htm
http://ws.ibs.org/niv/samples/ScriptureXHTML.htm
David
--
View this message in context:
http://sword-dev.350566.n4.nabble.com/Font-size-specification-inside-di
CAUTION NEWBIES:
In my previous example excerpt of code I wrote:
kjv->setText("jn.3.16");
This is a typo and should be:
kjv->setKey("jn.3.16");
Normally, I wouldn't worry too much, as the main point of the example-- the new
Render filter code-- was unaffected by the typo, BUT...
SWModule::s
Backwards compatibility maybe?
--
There are 10 types of people in this world. Those who understand binary and
those who do not.
---
David McClellan
On Jun 28, 2011 6:38 PM, "Greg Hellings" wrote:
> I'm curious as to why you opted to make another new filter set that
> was a copy of one, rather tha
I'm curious as to why you opted to make another new filter set that
was a copy of one, rather than just fixing the old one. What does
keeping htmlhref the way it is gain?
--Greg
On Tuesday, June 28, 2011, Troy A. Griffitts wrote:
> As discussed, I've added a new Render filter set: FMT_XHTML
>
>
As discussed, I've added a new Render filter set: FMT_XHTML
As usual, if you create your SWMgr asking for this Render output, you
will get the new markup:
SWMgr library(new MarkupFilterMgr(FMT_XHTML));
SWModule *kjv = library.getModule("KJV");
kjv->setText("jn.3.16");
cout << kjv->RenderText();
