Using ink from pen windows with new pen slates

[Borisg]

I first began using a pen PC in 1993, and I was hooked immediately. I made quite a few drawings using first an AST Pen portable and then a Compaq Concerto. Most of my ink has been saved in an undocumented compressed ink format that was produced by the VB3 equivalent of the new PenPicture control. I also have got other ink in uncompressed format which I did manage to decode, and I have programs which convert this to series of (x,y) points.

What I'd like to know is:
(1) has anyone found a way of getting the old compressed ink into a new table PC runnings windows XP? (and I mean as a collection of strokes, not by converting the old ink into a BMP and exporting it that way).
(2) Does anyone have details on new ink structures? I was able to decode uncompressed ink from pen windows using the information provided by Microsoft in their "Programmers Guide to Pen services" and some technical articles which were far more detailed in 1993 regarding the type of low level details I was interested in (like point to point timing data).

[fswitz]

Borisg,

I too have some old ink on a Grid, (my Concerto, is in TabletHeaven :( ). But my Visual C 1.5 won't load. I need that to get at my code.

But for #2. You should be able to reconstruct some ink. If you haven't taken a look at the TabletPC SDK, that is probably the place to start, The Ink and Stroke objects are pretty good sources for those details.

Ink data formats, of which ISF Ink Serialized Format, is the most prevelant are also discussed in the SDK. HTML and XML are also included. There are a number of good samples for Stroke management and identification on some of the sites as well.

good luck, keep us posted on your progress. I have a fond spot for Windows for Pen and would like to see some of it revisted.

[Borisg]

Hi Fritz:

Sorry to hear about your Concerto, I still like to use mine in the summer because the transflective screen means I can extend battery life by turning off the backlight and getting another 15 minutes or so out of the aging batteries.

I've looked at ISF object as defined in the Tablet PC SDK, and there is zero usefull information about the format. ISF is described as a highly compressed ink format which is nice to know, but it is manipulated by proprietary Microsoft code which may or not run on future platforms. The first thing I did when I got my TC1000 pen slate was to try to install W3.1 pen windows DLL's and VBX files that I needed to display ink. I could run all of my VB3 programs afterwards except for Pen windows programs (the error message was that I needed to install Pen windows!).

I'll give Microsoft credit for creating a better Tablet SDK this time in that I was easily able to write VB code to obtain stroke timing data and get (x,y) coordinates of every point in the stroke. To do this with the previous version of Pen Windows, I had to set a program like Notepad to raw inking mode and then decode the resultant raw ink data structure only when the ink structure was complete using some horrible VB3 hacks to do Windows API calls.

Microsoft already provides Tablet SDK for free, and it wouldn't hurt them to provide details of ink structure for people who might want to make further use of ink they've collected on platforms that Bill Gates might at some future date deem obsolete. I'm quite happy to use VB library calls to manipulate ink rather than writing my own code to perform the same function, but if these calls no longer work, I'd like to have documentation of the ink structure.

What I've decided to do is to store ink in my own clearly documented format. I've written a program in VB6 which stores all stroke data from my TC1000 in (x,y) format in a file and allows the ink to be redisplayed or analyzed. There are still problems in going between scaling from InkPicture control to Picture control (scaling factor appears to be about 1/1.8) and I'm just starting to look at relationship between InkWidth and width of a line drawn in a Picture window. Once I've cleaned up the code for this program, I'll post it here. One unique aspect of this program is that I did some of the programming without the benefit of a physical keyboard (one _cannot_ use the TC1000 keyboard while a passenger in a vehicle) and I was pleasantly surprised how well some of what I had previously viewed as annoying aspects of VB6 (like structure parameters drop down menus) facilitated pen only programming.

Nothing stops Microsoft from having propriatory routines to manipulate ink as 99% of users won't bother writing their own programs to manipulate the public ink structure. For those 1% of us who can't do what we need to with standard Microsoft code, Microsoft could do a lot to improve its image among hackers if it would make public details of ink structure.

[JonnyB]

Anyone interested in purchasing a AST Grid 2260 with no scratches and it works. It has Win 3.1 on it.

[Spencer]

quote:Originally posted by JonnyB

Anyone interested in purchasing a AST Grid 2260 with no scratches and it works. It has Win 3.1 on it.

How much?

[ArinG]

Boris,

First thing, let me say, we hear you.

I can't make any promises, but I understand your concerns.

The issues that you are having with the scaling in your control is most likely due to the fact that your Picture control is using Twips, while the ink is stored in Himetric. The ink space is defined as 2540/inch (.01 mm) for all screen resolutions (at 100%). You should take a look at the ScaleX and ScaleY functions in VB to do some simple conversions.

Thank you for you valuable input.

[Borisg]

quote:Originally posted by ArinG

Boris,

First thing, let me say, we hear you.

I can't make any promises, but I understand your concerns.

The issues that you are having with the scaling in your control is most likely due to the fact that your Picture control is using Twips, while the ink is stored in Himetric. The ink space is defined as 2540/inch (.01 mm) for all screen resolutions (at 100%). You should take a look at the ScaleX and ScaleY functions in VB to do some simple conversions.

Thank you for you valuable input.

Glad to know someone's listening. Since my last posting I've changed directions in how I'm pursuing my goal of acquiring timed ink. I was starting to wonder when a lot of the operations I was doing seemed to be duplicating stuff in the pen SDK, but the advantage I had was that I had all of the (x,y) points to play with. How I got to using SDK routines was somewhat unusual as I was a passenger in a vehicle and I couldn't find any way to type on my TC1000, so I had to use it in slate mode. I decided to use the 4 hours of travel time to read through the pen SDK and found myself using the pen to cut and paste bits of code from the sample section to VB. I used the debugger to verify ink data structures, and before I knew it, I had found a way of doing my application entirely with material from the pen SDK and more compactly than I imagined it would be. Another bonus is that I can take ink generated from my application and past it in windows journal, and also use my programs to analyze ink on non-pen computers.

My application involves patients drawing various nested simple figures and looking at drawing speed as a function of figure size. People with Parkinson's are much less able to increase their drawing speed with increased figure size compared to neurologically normal subjects and this may be a means of diagnosing/monitoring Parkinson's disease. What I require is precise timing data on every stroke, and I do this using TSC just because I have written routines to read TSC and perform arithmetic on 64 bit times. Every stroke is tagged with a timestamp giving start time of the stroke and it's duration in microseconds. The ability to add extra data to stroke data is a nice feature, using a UID seems a bit excessive, but when one compresses ink the inefficiences of implementation are not reflected in the size of the ink object. Another unexpected effect of copying ink to and from Windows Journal was that stroke ordering was changed; if one sorts by stroke start times then this problem is eliminated, but it was another annoyance to deal with.

I can use pen SDK routines to extract raw (x,y) data from ink strokes and these are used to calculate perimeters of the nested figures. Using pen SDK calls has made my code to change ink color and thickness much simpler. For this particular application I can calculate stroke timings and stroke lengths at the time the ink is collected so I don't really care about how the ink is stored except that it is nice to be able to reanalyze it if necessary and to look at it.

My analysis code was written in QuickBasic for Macintosh (another Microsoft annoyance; QuickBasic was a very nice development environment on the Mac, but the compiler could only be used in 24 bit mode and the programs only run properly if loaded into lowest 16 Mb of Mac RAM. If you're no longer going to support a product, release some details to help those of us who want to keep on using it in the future). Ink data was input as hexadecimal memory dumps of the uncompressed ink buffer that I had managed to locate by poking through Win3.1 memory (The book "Undocumented Windows" by Schulman et al was an excellent resource to find the information I needed at this time). I spent some time looking at the compressed ink structure of first pen windows and decided that it wasn't worth my time to hack since I could use VB to manipulate the ink. That was a mistake as I had a lot more time then to engage in such explorations than I do now.

If Microsoft were to make public the algorithm that it used to encode ink for the first version of pen windows, it wouldn't lose anything as I doubt that there are plans in the works to market software to convert from old format ink to new format ink, and it would enhance Microsoft's reputation. I like the new pen slates so much that I've bought another TC1000 to use full time in my office, but I'm not yet ready to start switching over to pen based systems as I've been burned in the past and Microsoft is going to have to start looking at people who have data and applicatons that span decades rather than the 3-6 month cycle of obsolesence that seems to be built into its products.

And I won't be using VB.NET at all. I installed a demo DVD that came with Dr. Dobbs journal and found that my programs needed such extensive modifications to go from VB6 to VB.NET that it was pointless trying to convert them. VB6 works for me now and, in my view, I see the philosophy behind VB.NET as providing another level of indirection between the hardware and my software. If I want safety, a sandbox and a virtual machine, I'll use Java, but VB6 is about as high level as I want to get.