Hi

Steve, some of your helpful error messages could perhaps benefit from some elucidation?

expected $ but got ... etc

Are you sure that error still occurs? I changed a lot of them during development. I don't see a message in the source with that form any more. I'm afraid you are going to have to give me specific examples, as they all make sense to me, since I wrote them!

I'm not quite sure how critical your spaces are in the xmp statement; also,can it include chr$(9) s?

They are only needed to separate words, you can use a tab instead if you like and you can have extra spaces or tabs. If you are using a space as a colour in the pixmap, then those spaces are significant of course. ..Steve

Nick

I meant that the error messages in the past were very helpful - particularly the line number refs - but for some may need to be explained more fully in a help file.

Oh OK, I missunderstood, sorry .

Now I don't get any msgs eventhough the code may be incorrect, ie

This is strange -- I do get errors for all these cases.

xpm="32 5 2 1" "0 c #C0C0C0" "1 c #000000" "12345611111111111111111111111111" "00000000000000000000000000000000"

I get the error: Compiling TYP txt file: Error: (t.txt:20): Tag '2' is not one of the defined colour pixels The term 'Tag' may be non-standard or incorrect and I'd be glad to replace the word with a more standard one. If the point was that there are not enough lines I get the error: Compiling TYP txt file: Error: (t.txt:21): xpm bitmap line must start with a quote: [end] This message could be expanded to explain that the most likely problem is that there is not enough image lines.

xpm="32 5 2 1" "0 c #C0C0C0" "1 c #000000" "1111111111111111111111111" "00000000000000000000000000000000000"

In cases when characters in a line do not match the xpm the typ file is simply not created, leaving the poor creator in a state of 'utter confusion' ;)

I get an error for the first line which is too short: Compiling TYP txt file: Error: (t.txt:21): short image line: "1111111111111111111111111" After repairing that line, there is indeed no error for the line that is too long. The extra data is just ignored so it isn't an error as far as the compiler is concerned, but probably should be checked since it is probably not what the creator intended.

I suppose it is a matter of debate/size of jar as to how essential error msgs are.

I'm happy to add any error message that is likely to happen, I don't think jar size is an issue for this. ..Steve

Hi Nick

btw any progress on true color pois with colormode 32 - although in my experience only Mapsource/Basecamp seem to render this type correctly.

I've now implemented colour modes 16 and 32 for the true colour image type. As usual I ignore any ColorMode=N declaration and determine the lowest colour mode that is required to represent the image and use that. Attached is the patch and a sample .txt file showing the different ways of writing the image. I've tested it against TYPWiz2 and you can round trip between the two programs. I'm not actually used the TYP files... ..Steve

Hi Nick

But I can see the wisdom behind #cc000011 and #cc0000 when alpha=0 I might change this in TYPWiz2 - thanx for the tip!

Great. You can also use the same format for the colours in the normal pixmap format too, although I can see that you might not want to change that for compatibility.

btw,have night versions been implemented as well?

Yes, night versions should work too. I think that TypWiz2 might not write odd width pixmaps correctly in true colour with colour-mode of 32. I write them the same way as the other images by padding each row to a byte boundary. TypWiz writes without any padding. It does however read the mkgmap generated one correctly, but fails on the one the one it wrote itself. Which way do you think is correct? ..Steve

Hi Steve Have been experimenting with w =odd L even w =odd L odd w sizes 3+ I used my bus bitmap to check as we've got 'millions' of bus stops in our area.Use Mapsource and my oregon to check . Used padding as you suggested but image always appeared as noise - even tried different lengths of padding. Without padding image is always rendered correctly, which seems to indicate that the alphas are parsed correctly? I had difficulty with bus stops width 3 or 5 as the pois were barely visible, even at my age ;) Degrees Opacity are maintained on Mapsource, though ,as always,not on the gps unit, but image is displayed correctly. I've downloaded yesterdays mkgmap but it didn't seem to parse truecols with colormode 32, as yet .. Nick -- View this message in context: http://gis.19327.n5.nabble.com/Wiki-page-about-TYP-files-tp5324444p5441311.h... Sent from the Mkgmap Development mailing list archive at Nabble.com.