Das eez kaput! Sometime around 2002 I spaced the entire database table that mapped individual entries to categories. Such is life. What follows is a random sampling of entries that were associated with the category. Over time, the entries will be updated and then it will be even more confusing. Wander around, though, it's still a fun way to find stuff.
iMortar will allow soldiers to connect, via Wi-Fi, to other mortars in their area.
We use to have a problem shooting at the same target, but once we network the mortars, once you select a target, other mortars in your network will not shoot at the same target, said an FSS spokesman wearing a black mask.Can I have your shoes? I have none.
Rather, I have in mind the brief notation of the day's highlight, the amusing encounter or useful insight that will someday evoke a memory of yourself when young. Such a journal entry perhaps an e-mail to your encoded personal file can now be supplemented by scanned-in articles, poems or pictures to create a "commonplace book." You will then have a private memory-jogger and resource for reminiscence at family gatherings.
1. The possessive form of a third person, singular, gender-neutral pronoun. Used to indicate possession, agency, or reception of an action by a gender-neutral being or person spoken of. Can be used to replace "his or her." 2) the third person singular pronoun in the nominative case, gender-neutral. other forms: huneself (reflexive).
ex. 1. Everyone must bring hune hat. 2. The person presented hune proposal. 3) Each person taught huneself to read.
Q wireless telephone..
ex. Honey, where's the space phone?
Sybarite \Syb"a*rite\, n. [L. Sybarita, Gr. ?, fr. ?, a city in Italy, noted for the effeminacy and voluptuousness of its inhabitants; cf. F. Sybarite.] A person devoted to luxury and pleasure; a voluptuary. web1913
sybarite n : a person addicted to luxury and pleasures of the senses [syn: {voluptuary}] wn
0045_
prefixes?); the meta data or commentary associated with an image; the
look and feel of the actual webpages. And while an all-in-one package
is always fun my experience has been that, in a slideshow, context,
they usually come at the price of zero-flexibility.
Apache::Album
is a pretty good example. It is a very cool and very easy widget to set
up. But, the HTML is hard-coded and meta data is stored free-form in YA
file that sits in the image directory and it only outputs HTML. So, I
spent the better part of two months, a while back, tearing the guts of
the package apart trying to make it more flexible with things like
subclasses for output formats, XPath-itis for meta data and all manner
of bells and whistles. I learned a bunch of stuff in the process but
ultimately failed to create anything more flexible or robust. One of
things I learned is that you can use ImageMagick to read and write
comments into image files which got me thinking that you could store
all of your metadata as an XML blob in the comments field. Which is
pretty interesting since when you think about it a directory listing is
basically a bare-bones slideshow. With some clever caching techniques
you could simply attach a server based handler to a directory of images
-- we'll ignore how you get the meta data in there for the moment --
and be done with it. Neat, huh? But I'm not a scholar on image formats
and I don't really know what the rules are about one application
respecting the comments that another application writes. And truth be
told, I'm not that interested in learning. So, that means we're back to
the stage where we've got a bunch of images and a bunch of XML files.
Or maybe we've got just one XML file. Either way, we've got this funny
bird that needs to be massaged before anything can be done with it. And
writing any kind of DTD is going to be a pain because everyone is going
to have some kind of random meta-ness they want added to their
slideshow. Attentive readers (or
David
who got to listen to this rant, last night) will have begun to
see
where this is going
:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" [
<!ENTITY % Slides SYSTEM
"http://www.aaronland.net/src/dtd/mod/xhtml/slide.mod">
%Slides;
]>
By redefining the XHTML
%Block;
and
%Flow;
entities, you can create a flexible slideshow format that is both
XML
fit for munging/transforming and
HTML
for easy viewing :
<!ELEMENT abstract (p*)>
<!ATTLIST abstract id ID #REQUIRED
class CDATA #IMPLIED
style CDATA #IMPLIED
title CDATA #FIXED "Abstract">
<!ELEMENT slide (meta*,a)>
<!ATTLIST slide sid ID #REQUIRED
class CDATA #IMPLIED
style CDATA #IMPLIED>
<!ENTITY % Block "(abstract,ul)">
<!ENTITY % Flow "(slide)">
The
ul
(yeah yeah, it should probably be an ordered list...) element can only
contain
li
elements.
li
elements are defined with the
%Flow;
parameter entity which means you can redefine your XHTML document to
validate as a single list, that contains one or more items. Each item
contains a "slide" which consists of zero or more meta tags (remember
them?) and a link. If all your fancy pants server tools are broken
you're still left with a list of named images that link to actual
images. Not great but better than than an XML document rendered as a
collapsible outline. So far, so good. But wait! There's more :
<Directory /path/to/image/directory>
DirectoryIndex index.html
SetHandler perl-script
PerlHandler Apache::ImageViewer
PerlSetVar ScaleSmall 25%
PerlSetVar ScaleMedium 50%
PerlSetVar ScaleLarge 75%
PerlSetVar ScaleThumb x50
<FilesMatch "index\.html$">
PerlModule AxKit
SetHandler perl-script
AxProvider Apache::AxKit::Provider::Filter
AxAddStyleMap text/xsl Apache::AxKit::Language::LibXSLT
AxAddProcessor text/xsl /site/xsl/slides/slide-tools.xsl
AxCacheDir /usr/local/www/htcache
AxDebugLevel 0
AxStackTrace Off
AxLogDeclines Off
AxNoCache Off
PerlHandler AxKit
</FilesMatch>
</Directory>
And while the example cited is mod_perl specific, there isn't much to
prevent it from being implemented in whatever environment suits your
fancy. All you need is a widget that can speak to ImageMagick and an
XSLT engine that can suck in CGI parameters :
sid
and
scale
. Those are the keys used to 1) tell the stylesheet whether or not to
render an image or an index and 2) tell the image widget which image to
display and
how big it
should be
. The next step is to write an XSLT stlyesheet to convert the XHTML
described above in to an
AxPoint
document.
download :
slide-tools 0.1
I'm not sure whether to laugh or cry.