Steve, Have been testing compiler for all types of polygons and polylines and have not come across any issues ; 1) btw it doesn't allow for font=normal (font) 2) Unfortunately,the truecolor poi rendering of say DayXpm="32 32 0 1" Colormode=16 is incorrect and causes mapsource to hangup. somehow, the above gets changed into DayXpm="32 32 0 2" Colormode=32 The length of the colour stream seems to be incorrect - see testmkg.typ I've created my own 16 bit version, testtwz.typ, which gets rendered correctly. Both are in a zip file : www.pinns.co.uk/osm/truecolor.zip I've been using 48x48 16 bit truecolor pois for weeks now on my gps and have not encountered any issues. Keep up the great work! Nick -- View this message in context: http://gis.638310.n2.nabble.com/true-color-problems-with-typ-compiler-tp7119... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Nick
1) btw it doesn't allow for font=normal (font)
OK I can make it recognise this. By the way, should Default be the same as Normal or should it be 0 in your opinion?
2) Unfortunately,the truecolor poi rendering of say
DayXpm="32 32 0 1" Colormode=16 is incorrect and causes mapsource to hangup.
Ah, a fix for another bug introduced that one. I only expect to read in colour mode 0 true colour images at the moment. The question is how to represent a true colour image with a transparent pixel. I would suggest DayXpm="2 2 0 1" "#124455" "none" "#124455" "none" and the compiler would pick an unused pixel to be the transparent one. I take that you are adding an extra pixel to the list and specifing the colour mode directly, something like this? DayXpm="2 2 0 1" ColorMode=16 "#ff00ff" "#124455" "#ff00ff" "#124455" "#ff00ff" Everywhere else I just ignore any specified colour mode and use the lowest colour mode that can represent the given image and I would like to be able to do that for true colour images too. Do you know if colour mode=32 true colour images are allowed? ..Steve
""Ah, a fix for another bug introduced that one. I only expect to read in colour mode 0 true colour images at the moment."" You've done the hard bit of squashing all those bytes! That explains why the stream is shorter. there are 5 / 8 known font options 0 = default 1 = Nolabel 2 = SmallFont 3 = Normal 4 = Large have not experimented to find out what values 5-7 do, if anything As you probably have gathered the first colour acts as a transparent colour, always placed as the first colour but I agree that would be confusing fornthe user. I've not represented 16 bit truecolor the way you suggested,ie replacing the transparent colour with 'none', but it does make sense for the user not to specify the transparent colour, ie to copy Garmins structure. yes, you can use 32 bit truecolor and amazingly specify level of opacity 0 - 15 for each pixel; it works well on my humble Oregon! I use: "#EDEBED" alpha 15 "#EDEBED" alpha 10 "#EDEBED" alpha 0 etc bytes needed for each color: 1.5 with 'last 4 bits' reserved for opacity -- View this message in context: http://gis.638310.n2.nabble.com/true-color-problems-with-typ-compiler-tp7119... Sent from the Mkgmap Development mailing list archive at Nabble.com.
oops : bytes needed 3.5 instead of 3 for each colour -- View this message in context: http://gis.638310.n2.nabble.com/true-color-problems-with-typ-compiler-tp7119... Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (2)
-
n Willink -
Steve Ratcliffe