Unstable but workable build of the sK1 available in SVN.
CDR files importer is included, so 'made with prepress in mind' files of version 7 to 13 /aka X3/ can be opened in sK1 now.
RevEngeLog for the last days:
- <arrw> (arrow descriptions),
- <loda> type 0x14 (Polygones),
- <outl> dash descriptions,
- rounding corners for rectangles,
- how <loda> type 5 is linked to <bmp >,
I'm going to RE stars, spirals and other fancy tools in a day or two after testing files will be available.
CDR uses (slightly modified) RIFF with standard LZW. Also
there are clearly
identifiable pointers to 'document-wise' parts like
fills and outlines parameters.
VSD uses OLE with 'customized' LZW version. There are a
lot of
entities there (I had ever asked native speakers to suggest
some good names for different kind of 'peaces'). The
relations mostly aren't clear.
A lot of time was wasted to find out LZW options (VSD).
cdr_explorer (and therefore sK1 importer) uses zlib
functions (CDR).
RIFF leaves some place to guess about chunk content because
of meaningful names (<obj >, <DISP>,
<IKEY>, <bmp >, <fntd>
can you guess what it is?).
In VSD _some_ parts of 'Visio Document Object Model' can be
found from the 'type value in the pointer to stream', also
one have to map chunk numbers to types.
For vsd/vss I stole some code from libgsf, but
my ability to adapt it is quite restricted. And I gave up
all attempts to make something useful in C with GObject.
For cdr Igor Novikov made a
cdr_explorer, that is really nice and handy.
So there are some details about the formats:
vsd
and cdr
(WARNING! Coarse (Russian) language. Viewer discretion is
advised! =)
For now CDR files (ver.7 to ver. X3) can be opened in sK1. Igor Novikov is going to
make two
presentations
about it at LGM-2
What could be my next target?
Well... there are some things to research in CDR ;-)
And show-stopper is not me (there are no more cdr files
prepared to make meaningful conclusions.) Maybe or maybe not
we will complete most of this job at LGM-2.
Alexandre
Prokoudine suggested that it could be interesting to dig
into photoshop related formats.
Jody pointed
to PPT.
So I'm encouraging Igor Novikov to extend cdr_explorer with
support for OLE.
It will help us to finish with VSD/VSS (and maybe create
some kind of viewer
for a time while Ian
Redfern implement VSD->..->Dia convertor)
and
provide a base for possible treatment of PPT.
I would rather work with PPT because I know who will be
responsible for utilization
of the collected data =).
And I believe that nobody really need any data about PSD
format and related staff.
ELT started today. Thanks to JIAS and Jewish community.
It seems to be quite difficult to improve vsdump more w/o at least "indirect access through experienced user" to Visio2k2 or 2k3. So I'm going to make some version of VSD/VSS viewer based on gtk+ or gnome.
Most of 'commercial' stencils made of a set of WMF and/or
EMF files.
While vsdump can't convert VSS directly to Dia or
Kivio stencil, it can extract all those WMF/EMFs.
It's not quite easy to preview WMF/EMFs (e.g. EOG doesn't
support this), so vsdump extracts an icons of
'Masters' and saves them in .ICO files.
Slightly tired with VSD/VSS reverse
engineering,
I made a small
utility to dump bitmap preview from CorelDraw files.
It's easy, so I would like somebody implement similar
functionality in EOG or gthumb.
Dear Lazy Web
One commercial software file format stores some raster images (icons) in the format described below:
Offset Length Value
2. . . . . 2. . . . . Width (always 0x20?)
4. . . . . 2. . . . . Height (always 0x20?)
8. . . . . 4. . . . . Size of file
0xE . . . . . . . . . start of transparency 'list'
[right after end of transperency] start of points colors
The start is in the left bottom corner.
Transparency: 1 bit per point
Points: 4 bits for color encoding
It utilizes some kind of RLE algorithm, so if
most significant bit of L=1 -- repeat next byte L&127
times
most significant bit of L=0 -- read L&127 bytes
'literally'.
----
May be you can recognize it as some well-known format?
Example:
00 00
20 00 (Width)
20 00 (Height)
16 00 00 00 (Size)
00 00 ???
02 c0 03 (2 most signif bits in the 1st byte and 2 least
signif bits in the 2nd bytes are transparent)
FE 00 (next 7e*8 bits are opaque)
/because transparency was described for all points next
bytes are colors/
08 FF 99 FF 99 99 FF 99 FF (2 white /in real transparent/, 2
red /color 9/, 2 white, 2 red points; 2 red, 2 white, 2 red,
2white /transparent again/ points)
FF AA (7f*2 green /color A/ points)
FF AA (7f*2 green /color A/ points)
FF AA (7f*2 green /color A/ points)
FB AA (7b*2 green /color A/ points)
end of file
So I have 2 questions:
1. How system assigns devices to /dev/<something>?
2. How to determine (command/utils/place in the 'cat <something>') which dev-id was assigned to the device?
At least when I used to configure /dev/input/event0 there was no any 'no such device' messages.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!