<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Valerie Sutton wrote:
<blockquote cite="midDA67806A-CCFB-4203-9E0E-1C1BDCC3DAB0@mac.com"
type="cite">SignWriting List <br>
April 29, 2007 <br>
<br>
So at least we are starting the process on our own site...but in
vertical columns... <br>
<br>
Regarding MediaWiki.... <br>
No need for PDF...that was just one idea...so throw that out ;-)) <br>
It sounds like that SWML-S then, would be the answer from what you say
below... <br>
</blockquote>
Val, Steve and Gerard,<br>
Sounds to me like SWML-S or the new STML would fit the needs well.
One option to display any of these XML formats would to be use an
XML Stylesheet. I transforms the XML at the browser level and convert
it to HTML to show the symbols each in their respective places. I had
posted some of these quite a while back. <br>
For it to work, you would need:<br>
<ol>
<li>The whole IMWA in png in one directory to get the symbols from
(This can be anywhere on the Internet)</li>
<li>Have the xslt file on the same server as the XML file (I tried
putting it on another server but it didn't work for me, Maybe somebody
else knows a workaround for this one)</li>
<li>Have the following reference in the XML file to the stylesheet.
<?xml-stylesheet type="text/xsl" href="swml.xslt"?></li>
<li>A web Browser that can handle XML transforms. (Both Firefox and
Internet Explorer handle these I don't know about the others)</li>
</ol>
Things that would need to be done to make the stylesheet work nicely.<br>
<ol>
<li>Get the SignWriting to display properly. Currently, the signs
have a lot of space between them. Some adjustment may have to be made
for the horizontal positioning as well.</li>
<li>Split the Output into several columns using a Table and
<td> tags every so many signs. <br>
</li>
<li><br>
</li>
<li>Whatever other programming is needed to pass the XML file to the
SignPuddle and back (I have a stylesheet that can send reopen the XML
with the canvas page on the SignPuddle. Though this may not be the
most efficient way of doing it)<br>
</li>
</ol>
I hope to have time put a small demonstrations together to show you
what I mean.<br>
<br>
Anyways, first, I wanted to hear what the three of you, and everybody
else on the list of course think of this possible solution.<br>
<br>
Jonathan<br>
<blockquote cite="midDA67806A-CCFB-4203-9E0E-1C1BDCC3DAB0@mac.com"
type="cite"><br>
or whatever...time will tell what will be best! <br>
<br>
We will work out all those licenses to make everyone feel good about
the licenses we choose...I want to thank Pharos for a description of
all the licenses too! So I hope to read that soon... <br>
<br>
Thank you so much for your advice and support - <br>
<br>
Yes...we will get there! <br>
<br>
Val ;-) <br>
<br>
-------------- <br>
<br>
<br>
<br>
<br>
On Apr 29, 2007, at 11:46 AM, GerardM wrote: <br>
<blockquote type="cite">OmegaWiki exists in two planes; there is the
standard MediaWiki functionality. This is the functionality that you
see in the portals. And there is an extension to MediaWiki that is
specific to OmegaWiki. This is the functionality that allows us to work
on lexical, terminological and ontological information it allows us to
represent database information in many user interfaces. <br>
<br>
Storing discrete information is probably easiest done in the "Wikidata"
functionality. Storing text information that is in a fixed, unmutable
format in MediaWiki is quite contrary to the core ideas of what a Wiki
stands for. In a Wiki an article is started by someone and someone else
takes it further and in the process may become quite different from the
original incarnation. This means that having the content in a PDF kinda
way is not really feasible. When the information of an article is
stored in a XML format, the data is not stored in a fixed way. It
therefore allows people to get it, change it and save it. MediaWiki has
a history mechanism that allows for saving changes. <br>
</blockquote>
<br>
<blockquote type="cite">When Steve mentions copyrights, it is
important to realise that the copyright stays with the copyright
holder. The copyright holder can extend a license to someone else and
also provide the same data or programming under many licenses. The key
thing to appreciate is what is it that you aim to achieve. My
understanding is that you aim to emancipate the sign languages and
allow the deaf to register their own history and culture in their own
language. This means to me that the more functionality allows for the
use of sign languages exists, the better your aims will be achieved. <br>
<br>
There are key technologies to consider. Valerie holds the copyright to
the characters. She wants everyone without restrictions to be able to
use the SignWriting characters. The SignPuddle software and much of the
other software is freely available for all to have. It however does not
state license information and consequently many people who are aware of
licenses are hesitant to use it. There are licenses specific to fonts,
there are licenses specific to software, there are licenses specific to
data and, database designs are licensed too typically under a software
license. <br>
<br>
When MediaWiki is to be adapted to use SignWriting, there will be a
need to do some research to understand what it is that needs doing.
This does not imply a necessity for UNICODE. It implies careful
analysis. I agree with Steve that there will be many ways to skin this
cat however, what is considered the MediaWiki functionality has to be
there in order for it to be a success. <br>
<br>
MediaWiki is GPL licensed. This has particular implications, one of
them is that when you get GPL licensed software you are Free to use it
and change it but you are not free to change the license of the changed
product. All in all licenses are not easy and they are certainly not
something that you want to rush into. <br>
<br>
First and foremost is, what is it that you want to achieve and how do
you achieve these things best. This is not something to rush. Yes we
can have Wikipedias in SignWriting, but to get there we will have to
take time to consider the requirements carefully. <br>
<br>
Thanks, <br>
GerardM <br>
<br>
<a class="moz-txt-link-freetext" href="http://mediawiki.org">http://mediawiki.org</a>
<br>
<br>
On 4/29/07, Valerie Sutton < <a class="moz-txt-link-abbreviated"
href="mailto:signwriting@mac.com">signwriting@mac.com</a>>
wrote:SignWriting List <br>
April 29, 2007 <br>
<br>
On Apr 29, 2007, at 9:12 AM, Steve Slevinski wrote: <br>
<br>
> Hi Val, <br>
> <br>
> This would be an easy extension for any website. Upload a zip
file <br>
> of the column images or download a zip file. We'd need a server <br>
> side and the AJAX viewer. We could create add-ons for OmegaWiki, <br>
> using a copyright compliant license. We could also make the
viewer <br>
> a free download for other websites to help promote the use of <br>
> SignWriting. <br>
> <br>
> Write in SignPuddle, export the columns as a zip. Upload the zip <br>
> file to the website. We could also include the SWML in the zip. <br>
> Very easy to use for now and for later when the SWML is used
directly. <br>
> <br>
> I'm rewriting SWML into STML for the new SignText. It will
include <br>
> PDFs as well. Does any have the software list for splitting and <br>
> combining PDFs. The Mac and the PC are both unique. <br>
> <br>
> Regards, <br>
> -Steve <br>
<br>
<br>
-------------- <br>
<br>
Hi Steve! <br>
This sounds amazing and I look forward to Gerard's communication <br>
about this... <br>
<br>
It will be a real boon for Sign Languages around the world to have <br>
these features to use quickly on other web sites...thank you, Steve! <br>
<br>
Regarding the question about splitting and combining PDFs...obviously <br>
the best solution someday, is to have the actual document inside <br>
SignText, export with page breaks, so that the page breaks are a part <br>
of the PDF created from the beginning...the SignText PDF should <br>
someday be able to create multiple-paged-PDFs from the start, <br>
eliminating the need for combining PDFs... <br>
<br>
Until that day comes, the best program to use, which is for both Mac <br>
and PC, is the Adobe Acrobat Professional program, which is the way <br>
most people edit and combine PDFs. In Acrobat Professional you can do <br>
so much...including changing actual text and graphics, and you can <br>
insert, delete, replace pages in a variety of formats and so forth... <br>
<br>
As far as free programs that do that...there are hundreds it seems... <br>
<br>
and there are source code for some of these programs free on the web...
<br>
<br>
For example... <br>
<br>
here is the source code for one of them on the Macintosh: <br>
<a class="moz-txt-link-freetext"
href="http://www.monkeybreadsoftware.de/Freeware/CombinePDFs.shtml">http://www.monkeybreadsoftware.de/Freeware/CombinePDFs.shtml</a>
<br>
<br>
and here is one on the PC: <br>
<a class="moz-txt-link-freetext"
href="http://www.softaward.com/text/free-download-9801.html">http://www.softaward.com/text/free-download-9801.html</a>
<br>
<br>
<br>
Val ;-) <br>
<br>
</blockquote>
<br>
<br>
<br>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<meta content="text/html;" http-equiv="Content-Type">
<title></title>
<br>
<div class="moz-signature">
<address><font face="Comic Sans MS"><big><font color="#6633ff">Jonathan
& Yolaine Duncan<br>
<span class="moz-smiley-s11"><span> 8-) </span></span>&<span
class="moz-smiley-s3"><span> ;-) </span></span></font>
<br>
<br>
</big></font></address>
</div>
</div>
</body>
</html>