- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Mike5
Admin
Admin
Sure, storing an array of numbers where adjacent pairs of numbers are supposed to be a single item is a silly looking data format, even ignoring the XML nonsense, but this isn't TheDailyGoodIdea.com after all.
Or maybe the numbers were made up to ilustrate the silly data format, but that's why we all hate the site and never read the stories here.
Admin
It looks like you guys are missing the fact that maybe one of the requirements was too keep track of the way the signature was written. Too keep compatibility to the max i would have designed something to store each value in Hex (so no need to serialize or something) with 2 initial bytes for the version, maybe 2-3 bytes for a signature, 4 bytes for the number of signature points that follow(0-64k in Hex), and then 6 bytes for each point ( 12 bits for x, 12 bits for y -> 3 bytes stored in Hex in 6 bytes).
You'd have version information and the initial version would support from the start more than twice the maximum number of points a 300x100 bitmap would have supported and support for 4k x 4k bitmaps.
Admin
Good spam, I'm off to taipei ladle .com
Admin
Well, a long time ago I looked into using webservices from a PDA. It seems that the CE.NET guys never came around to creating a serializer as part of the package. I remember finding an example that used some XMS handwritten serialization to transport a signature as an example. It used the same (kind of) format. Maybe the original programmer just stole that example without thinking?
I went in a somewhat different direction to solve MY problem.
Admin
the REal REAL WTF is why did they even think to use a useless technology like XML in this case or JSON or anything else and just use a fricking flat file...
X,Y X,Y X,Y X,Y
I can parse it 10,000X faster than any of you guy's fancy technology, it's easily debugged by humans, and honestly has a far lower resource need.
Why is it you guys think you have to apply a "technology" to things that dont need it?
Admin
Blatantly the best solution would have been to use a pen and paper; It's more easily debugged by humans, has less disk storage space needed, and lets you keep a hard copy of it.
Who needs technology, eh?
Admin
Admin
So yes, JPEG (...photography...) is a lousy format for bilevel images, so one should use JBIG or other format designed for bilevel images.
Admin
<d>x1,x2,x3,x4...xN</d>You have your XML.
Admin
^_^ And then
xmlResult.Replace("LOL", "Signature") ;
Admin
Admin
It makes perfect sense mod 1, mod 2 or mod 273 (etc).
Admin
Admin
Admin
lmao!
Admin
[quoteReally though, you should just offload the work to the data input device and get it to send you a fricking jpeg.[/quote]
Compression noob; image without gradients => GIF.
Unless the supervisors have very artistic signatures.
Admin
I think your getting a bit lost now.... You should use much more xml :-
<TheWholeSignature> <signature> <FirstPixel> <x> 87 </x> <y> 21 </y> <pixelcolourdepth> 8 </pixelcolourdepth> <timeofpixelcaptured> 09:30:00:01 </timeofpixelcaptured> <dateofpixelcaptured> 01/01/2009 </dateofpixelcaptured> <PressureOfPixel> 50 </PressureOfPixel> <temperature_at_time_of_pixel_capture> 19.5 </temperature_at_time_of_pixel_capture> <temperature_scale> C </temperature_scale> <check_digit> 00043789234092345728034980329850287340980 </check_digit> </FirstPixel> .. .. </signature> </TheWholeSignature>Do you think I need a check digit for x AND for y ? or will just the one do ?
Admin
LMAO
or should that be <LMAO> LMAO </LMAO>
or even <LMAO> <FirstDigit> L </FirstDigit> ..... </LMAO>