281 lines
24 KiB
HTML
281 lines
24 KiB
HTML
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Be Newsletters - Volume 1: 1995–1996</title><link rel="stylesheet" href="be_newsletter.css" type="text/css" media="all" /><link rel="shortcut icon" type="image/vnd.microsoft.icon" href="./images/favicon.ico" /><!--[if IE]>
|
||
<link rel="stylesheet" type="text/css" href="be_newsletter_ie.css" />
|
||
<![endif]--><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><link rel="start" href="index.html" title="Be Newsletters" /><link rel="up" href="volume1.html" title="Volume 1: 1995–1996" /><link rel="prev" href="Issue1-32.html" title="Issue 1-32, July 17, 1996" /><link rel="next" href="Issue1-34.html" title="Issue 1-34, July 31, 1996" /></head><body><div id="header"><div id="headerT"><div id="headerTL"><a accesskey="p" href="Issue1-32.html" title="Issue 1-32, July 17, 1996"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a accesskey="u" href="volume1.html" title="Volume 1: 1995–1996"><img src="./images/navigation/up.png" alt="Up" /></a> <a accesskey="n" href="Issue1-34.html" title="Issue 1-34, July 31, 1996"><img src="./images/navigation/next.png" alt="Next" /></a></div><div id="headerTR"><div id="navigpeople"><a href="http://www.haiku-os.org"><img src="./images/People_24.png" alt="haiku-os.org" title="Visit The Haiku Website" /></a></div><div class="navighome" title="Home"><a accesskey="h" href="index.html"><img src="./images/navigation/home.png" alt="Home" /></a></div><div class="navigboxed" id="naviglang" title="English">en</div></div><div id="headerTC">Be Newsletters - Volume 1: 1995–1996</div></div><div id="headerB">Prev: <a href="Issue1-32.html">Issue 1-32, July 17, 1996</a> Up: <a href="volume1.html">Volume 1: 1995–1996</a> Next: <a href="Issue1-34.html">Issue 1-34, July 31, 1996</a></div><hr /></div><div class="article"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Issue1-33"></a>Issue 1-33, July 24, 1996</h2></div></div></div><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Engineering1-33"></a>Be Engineering Insights: Infrared</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Guillaume</span> <span class="surname">Desmarets</span></span></div></div></div><p>
|
||
The happy campers among you who, day after day, enjoy the presence of a
|
||
BeBox may have already removed the chassis cover to see if we really
|
||
shipped two PowerPCs per BeBox ("...yup, there they are..."). The most
|
||
courageous may then have decided to take a further look at the
|
||
motherboard; eight SIMM slots (check), ISA slots (check), PCI (check)
|
||
third processor socket (che...what??? sorry, it's just the logic analyzer
|
||
port).
|
||
</p><p>
|
||
And over here we have the U30...
|
||
</p><p>
|
||
The U30 is an 8-bit microcontroller located between the logic analyzer
|
||
port and the ISA slots. More congenially, the U30 is the infrared (IR)
|
||
chip. This article describes the history and features of this chip.
|
||
</p><p>
|
||
The goal of the BeBox IR port is to enable the BeBox to interact with
|
||
consumer IR devices. Not only can the IR port receive commands from a
|
||
regular IR remote control, it can send control signals to an external
|
||
device—in other words, you can turn your BeBox into a big blue remote
|
||
control. The goal for now isn't to support standards like IrDa, we just
|
||
want a cool feature (almost as cool as the <span class="trademark">GeekPort</span>™).
|
||
</p><p>
|
||
In implementing the port, we needed to find an IR format that we could
|
||
support. The original idea was to sample a few specific remote controls
|
||
and then try to understand all the messages that they could send. We
|
||
planned on choosing generic, programmable models that had large numbers
|
||
of keys. On the out-going side, we needed to be able to sample an IR
|
||
sequence and reconstitute it later. Finally, we wanted the transceiver
|
||
(the box that receives and sends the IR signals) that's plugged into the
|
||
IR port to be as simple as possible... ideally, as simple as an IR LED
|
||
(for the emitting side). Consumer IR signals are time modulated, so in
|
||
addition to broadcasting data, the IR port needs to deliver a
|
||
time-modulated signal.
|
||
</p><p>
|
||
Unfortunately, after gathering information about IR and sampling all the
|
||
IR remote controls that were lying around at Be, we concluded that no two
|
||
protocols were exactly alike. (Some conclusion!) For example, each time
|
||
you press a key, you send a data field and an identification field
|
||
related to the device. Hmm.... Timings, data and identification fields,
|
||
synchronization fields, modulation frequency, repeat patterns—all
|
||
different!
|
||
</p><p>
|
||
It was time to resort to the old science fiction standby: The "universal
|
||
translator." You have a room filled with people from Earth, Venus, and
|
||
outer space colonies—yet everyone is speaking English! (How
|
||
convenient.) What does it mean? In order to ease communication, you
|
||
accept that you will lose part of the data that you receive when someone
|
||
is talking to you, particularly language-specific nuances. In fact, you
|
||
don't even know what language the other person is using. The only problem
|
||
is that your universal translator has to recognize every language that it
|
||
hears; if the range of languages is too broad to *teach* it each one (or
|
||
if new languages are created), then the translator has to have the
|
||
ability to *learn* new languages on its own. Back on Earth, California,
|
||
Menlo Park, that's what our IR chip tries to do.
|
||
</p><p>
|
||
First of all, the tasks of listening to a remote control (so you can
|
||
control the BeBox by using a remote), and emitting IR signals (so you can
|
||
control an external device from the BeBox) are clearly divided into two
|
||
modes: The first we call "analysis" mode; the second is "sampling" mode.
|
||
</p><p>
|
||
To use the BeBox to receive IR signals, you put the chip in analysis mode
|
||
and then teach it what to listen for by punching the set of keys (on the
|
||
remote control) that you want to use. During analysis, the chip looks for
|
||
a set of (eight or fewer) bits that remain constant; it assumes that this
|
||
is the identification field for your remote control. It then assumes that
|
||
the changing bits (again, as many as eight) make up the data field.
|
||
</p><p>
|
||
Once a remote control has been analyzed, the data can be stored in a
|
||
library of remote control settings. By choosing a remote from the
|
||
library, the user tells the chip to begin listening for signals that
|
||
match the analysis data. The chip then only processes incoming messages
|
||
that contain the proper ID bits. The chip can listen to three different
|
||
remote controls at the same time: There are three IR channels, and each
|
||
channel can be set up to recognize a different ID.
|
||
</p><p>
|
||
Sending IR signals to an external device also requires a learning phase.
|
||
You put the chip in sampling mode and then (once again) step through the
|
||
remote control keys that you're interested in. In sampling mode, however,
|
||
there's no analysis—the chip is simply recording the signals that it
|
||
receives. Later, when the user is using the BeBox to control an external
|
||
device, the chip simply plays back the signal that corresponds to a
|
||
particular requested function. Thus, for example, when you want to use
|
||
your BeBox to tell your television to change to channel 65, the IR chip
|
||
simply replays the "change to channel 65" signal.
|
||
</p><p>
|
||
This raises a question: Why doesn't the IR chip use the analyzed data for
|
||
output as well as input? Why does it have to play back a recorded signal
|
||
when it's talking to an external device, rather than synthesizing the
|
||
signal from the analysis data? It's a valid request—but,
|
||
unfortunately, it can't be done (at least not yet). During analysis, a
|
||
lot of important information is lost; only the ID and data field
|
||
information is retained, everything else—timing information in
|
||
particular—is thrown away.
|
||
</p><p>
|
||
Although a few remote controls won't work with the BeBox, a very large
|
||
number of brands are supported. Still to come is the software that will
|
||
use the IR chip.
|
||
</p></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="DevProfile1-33"></a>Be Developer Talk: Robert Poole, Leonid Software</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Robert</span> <span class="surname">Poole</span></span></div></div></div><p>
|
||
After a somewhat mediocre career in undergraduate physics, I decided that
|
||
a different course of action was in order. So I became a hacker.
|
||
</p><p>
|
||
I've done a variety of things with computers. My great love is graphics
|
||
—especially algorithms for generating really cool images, or for
|
||
transforming existing images. I played extensively with ray tracing and
|
||
image manipulation (sharpening, enhancing, posterizing, and so on)—I
|
||
know, I know, most of these tools are readily available for many
|
||
different platforms, but I wanted to write my own. Besides, being an
|
||
Amiga fan, I have little choice in the matter.
|
||
</p><p>
|
||
After a couple of jobs in the industry (including writing PDF conversion
|
||
software at MasterSoft), I decided to start writing software for myself
|
||
again. As the sole employee of Leonid Software, I consult by day and
|
||
write the software that I really want to write in the evenings. I've got
|
||
several software ideas kicking around:
|
||
</p><ul class="itemizedlist"><li><p>
|
||
A <acronym class="acronym">PNG</acronym> graphic toolchest, to convert images to and from <acronym class="acronym">PNG</acronym> (a
|
||
relatively new graphic file format), to view them, to apply
|
||
transformations to them, and to edit the various chunks that comprise a
|
||
<acronym class="acronym">PNG</acronym> file, as well as to append new chunks.
|
||
</p></li><li><p>
|
||
A <acronym class="acronym">PDF</acronym> viewing application, useful to developers since much on-line
|
||
documentation is now written in the <acronym class="acronym">PDF</acronym> file format.
|
||
</p></li><li><p>
|
||
I'm negotiating with a game development company to port a sound
|
||
toolkit to the BeBox.
|
||
</p></li></ul><p>
|
||
The BeBox for me is like the Amiga—full of promise and capable of
|
||
doing more with less. To me, the idea of an inexpensive multiprocessing
|
||
personal computer is a logical next step in PC evolution, and I'm amazed
|
||
nobody has pushed such a design previously. The <span class="trademark">BeOS</span>™ is clean,
|
||
object-oriented, and logical. The GUI is simple, yet slick.
|
||
</p><p>
|
||
The BeBox has let me recapture the euphoria I had lost when I sold my
|
||
Amiga 3000 to pay for a Pentium box. On the down side, there are plenty
|
||
of bugs and shortcomings to work out. I'm particularly annoyed at the
|
||
lack of support for foreign file systems in the BeOS—one simply
|
||
expects to be able to read an ISO 9660 CD-ROM volume without effort! But
|
||
the hardware is good (thank you, Be, for including SCSI as a standard
|
||
bus!), and the OS is constantly being improved. So the immediate
|
||
shortcomings can be overlooked.
|
||
</p><p>
|
||
I plan on making my BeBox products available as shareware over the
|
||
Internet. That's really the best distribution method for a one-man show
|
||
like myself. In the long run, I'd like to create a whole suite of
|
||
document and graphic processing applications for the BeBox, and I think
|
||
it's not unrealistic for a company starting small to do this. That's how
|
||
others have started. As for my target audience, it's clearly graphics and
|
||
DTP enthusiasts (with a heavy leaning toward graphics initially, because
|
||
for me that's less difficult).
|
||
</p></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Gassee1-33"></a>Fun and Games</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Jean-Louis</span> <span class="surname">Gassée</span></span></div></div></div><p>
|
||
In coming weeks we'll be featuring a column by Pierre Raynaud-Richard
|
||
that will address two components of the upcoming Developer Release 8 of
|
||
the BeOS: The Game Kit and the 3-D Kit. This marks an important step in
|
||
the evolution of the BeOS and, as such, deserves some clarification and
|
||
expanding upon the philosophy behind our moves.
|
||
</p><p>
|
||
First, the Game Kit. As Pierre points out, he wrote a fairly basic first
|
||
installment with enough functionality to encourage use and feedback --
|
||
feedback we'll use for the "fully functional" revision. After that we'll
|
||
be in "continuous improvement" mode, until technology or market changes
|
||
call for a major release. That's the theory, a little too tidy perhaps
|
||
when compared to implementation, but a usable framework when describing
|
||
our approach. On occasion, we'll depart from that model if and when we
|
||
decide to take out a part of the system and rebuild it from scratch. From
|
||
painful experience, we'd rather suffer (and cause others to suffer with
|
||
us) a temporary inconvenience than to live with our sins forever. In a
|
||
way, this sort of effort is a fleeting luxury, one we can afford in the
|
||
early days of the system when the concrete hasn't set and we can still
|
||
move the foundation walls.
|
||
</p><p>
|
||
Back to the Game Kit... The second point about the Game Kit concerns
|
||
facilitating what programmers will do anyway—with or without our
|
||
support or approval. In this case, game developers want and will write
|
||
directly to the screen. This epiphany was easier for Pierre than for most
|
||
systems programmers: He wrote games that were his calling card when we
|
||
hired him. Only later did he also reveal he writes science fiction. Doom
|
||
and other best-selling games contravene programming guidelines on systems
|
||
such as DOS/Windows that make the breach relatively easy. Frequently,
|
||
these games aren't available at all (and therefore don't help sales) on
|
||
systems such as the Macintosh, because these systems make such invasions
|
||
too difficult. Picking our challenge was easy: We'll take the problems
|
||
and the sales. If we do a good job with the Game Kit, we might even
|
||
minimize the problems associated with high-speed writing to the screen
|
||
without hurting game quality—and sales—too much. In the BeOS, we're
|
||
cognizant of the realities of office life: Games take over the screen in
|
||
one of the system's workspaces. This helps users avoid the
|
||
misunderstandings and lengthy explanations about the relaxing and
|
||
reflection-enhancing virtues of games: Switching to a more mundane
|
||
workspace is one keypress away. We're of the school that thinks there's
|
||
no serious computer without a serious inventory of games. The Game Kit
|
||
reflects this philosophy.
|
||
</p><p>
|
||
The 3-D question calls for more complex answers, and Pierre points to the
|
||
difficulty of a "one size fits all" API. Many have suggested we license
|
||
OpenGL®, so we're doing that now. I've just executed the licensing
|
||
agreement, and we can expect the port to be completed in the near future
|
||
(not for DR8, but soon thereafter). The good news is that OpenGL® is a
|
||
liked and respected industry standard. Silicon Graphics has done a great
|
||
job of promoting it, and as the smoothness of the licensing process
|
||
attests, the "Open"in OpenGL® is not there in vain. It will be attractive
|
||
for high-end applications, and it represents yet another installment in
|
||
our effort to make it easy, or easier at least, for some UNIX
|
||
applications to migrate to the BeBox. This effort started when we
|
||
realized we could progressively implement a fairly complete Posix API in
|
||
the BeOS. We also decided to build a separate 3-D Kit in the BeOS.
|
||
Simpler or more interactive 3-D applications are not best served by an
|
||
API originally designed for high-end CAD work. The full 3-D Kit isn't
|
||
implemented yet, even if the project is fully scoped in Pierre's papers.
|
||
Just as many hardware and software developers found color wasn't merely
|
||
more bits per pixel, we know 3-D isn't the visual space we know, with
|
||
just one more dimension. Success will stem in great part from our fine
|
||
tuning of the architectural choices we've made and, for this, developer
|
||
feedback is even more important than usual. The first public
|
||
demonstrations will take place at the Boston MacWorld Expo in August. We
|
||
hope to see you there or soon thereafter.
|
||
</p></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="BeDevTalk1-33"></a>BeDevTalk Summary</h2></div></div></div><p>
|
||
BeDevTalk is an unmonitored discussion group in which technical
|
||
information is shared by Be developers and interested parties. In this
|
||
column, we summarize some of the active threads. To subscribe to
|
||
BeDevTalk, visit the mailing list page on our web site:
|
||
http://www.be.com/about_be/mailinglists.html.
|
||
</p><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id491682"></a>WEEK 2</h3></div></div></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id491688"></a>Subject: First Experiences</h4></div></div></div><p>
|
||
More opinions on the shutdown mechanism, plus a new proposal: The
|
||
interface (probably some designated portion of the Browser) should
|
||
indicate whether it's safe to turn the computer off. This was countered
|
||
with the position that the computer can't really know for sure if it's
|
||
safe—you have to perform an explicit sync between the file system
|
||
and the database.
|
||
</p></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id491705"></a>File Format</h4></div></div></div><p>
|
||
In this thread (which finally separated itself from "Speaking of
|
||
PostScript...") the previously proposed system-level data translation
|
||
mechanism was critiqued. As an alternative, EAIFF 85 (Electronic Arts
|
||
Interchange File Format) was suggested. And rebutted.
|
||
</p></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id491721"></a>Subject: Speaking of PostScript...</h4></div><div xmlns:d="http://docbook.org/ns/docbook"><h5 xmlns="http://www.w3.org/1999/xhtml" class="subtitle">AKA: Content Negotiation Protocol</h5></div></div></div><p>
|
||
This has turned into a mail filter/type discussion. Should Be create a
|
||
mail filter daemon that lets you describe the sort (and amount) of mail
|
||
you're willing to accept? Should Be invent a new mail data format?
|
||
(This evoked mutterings of "NeXTMail.")
|
||
</p></div></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id491742"></a>NEW</h3></div></div></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id491748"></a>Subject: Root Directories</h4></div><div xmlns:d="http://docbook.org/ns/docbook"><h5 xmlns="http://www.w3.org/1999/xhtml" class="subtitle">
|
||
AKA: Root Dir Proposal<br />
|
||
AKA: Remembering Mounted Volumes
|
||
</h5></div></div></div><p>
|
||
In the hottest thread of the week, the philosophy of what goes into the
|
||
root directory was discussed. Should "/" contain the expected UNIX-like
|
||
directories (/dev, /tmp, etc.)? Should a CLI view of the file system be
|
||
any different from that presented by the Browser; specifically, what
|
||
should the Browser present as "/"?
|
||
</p><p>
|
||
Woven into the thread was a debate on how partitions/volumes should be
|
||
handled: Should mount point locations be restricted? How should the
|
||
BeOS handle a request to eject a mounted (removable) disk?
|
||
</p><p>
|
||
Also: Will Be do links? Multi-user? Automount?
|
||
</p><p>
|
||
THE BE LINE: Remember, the file system rewrite is coming. As far as the
|
||
design details go, we'll keep you posted. Until then, this thread is
|
||
being closely watched—your suggestions and observations aren't
|
||
wasted.
|
||
</p></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id491790"></a>Subject: Converting Pathname to Fileref</h4></div></div></div><p>
|
||
How do you get the ref for the current working directory? The doc for
|
||
<code class="function">get_ref_for_path()</code> claims that it doesn't accept relative paths; some
|
||
have experienced otherwise.
|
||
</p><p>
|
||
THE BE LINE: The doc is (philosophically, at least) correct: You
|
||
shouldn't pass a relative pathname to <code class="function">get_ref_for_path()</code>. This is
|
||
because the meaning of cwd in the ref/database world is undefined
|
||
(note, however, that this issue is in the file system rewrite hopper).
|
||
If you want to pass args, use <code class="classname">BApplication</code>'s
|
||
<code class="methodname">ArgvReceived()</code>.
|
||
</p></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id491828"></a>Subject: Standard Shared Libs</h4></div></div></div><p>
|
||
A call was made for folks to volunteer to implement common freeware
|
||
(and the like) as shared libraries. It was suggested that add-ons might
|
||
be a better approach.
|
||
</p></div></div></div></div><div id="footer"><hr /><div id="footerT">Prev: <a href="Issue1-32.html">Issue 1-32, July 17, 1996</a> Up: <a href="volume1.html">Volume 1: 1995–1996</a> Next: <a href="Issue1-34.html">Issue 1-34, July 31, 1996</a> </div><div id="footerB"><div id="footerBL"><a href="Issue1-32.html" title="Issue 1-32, July 17, 1996"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a href="volume1.html" title="Volume 1: 1995–1996"><img src="./images/navigation/up.png" alt="Up" /></a> <a href="Issue1-34.html" title="Issue 1-34, July 31, 1996"><img src="./images/navigation/next.png" alt="Next" /></a></div><div id="footerBR"><div><a href="http://www.haiku-os.org"><img src="./images/People_24.png" alt="haiku-os.org" title="Visit The Haiku Website" /></a></div><div class="navighome" title="Home"><a accesskey="h" href="index.html"><img src="./images/navigation/home.png" alt="Home" /></a></div></div><div id="footerBC"><a href="http://www.access-company.com/home.html" title="ACCESS Co."><img alt="Access Company" src="./images/access_logo.png" /></a></div></div></div><div id="licenseFooter"><div id="licenseFooterBL"><a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/" title="Creative Commons License"><img alt="Creative Commons License" style="border-width:0" src="https://licensebuttons.net/l/by-nc-nd/3.0/88x31.png" /></a></div><div id="licenseFooterBR"><a href="./LegalNotice.html">Legal Notice</a></div><div id="licenseFooterBC"><span id="licenseText">This work is licensed under a
|
||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/">Creative
|
||
Commons Attribution-Non commercial-No Derivative Works 3.0 License</a>.</span></div></div></body></html>
|