Hi Gerd
I tried various approaches to fixing "Find" when the fixed length Mdr17
(maybe also Mdr12) prefix contains sort.expand chars and couldn't make
it work. I could documents these attempts in Sort.java if you feel this
is worthwhile.
New patch attached that, for cp1252, leaves "ß" as its own
Hi Gerd
Just starting to read the new code more carefully and a few comments:
In Mdr17 the following line should be deleted:
len = (len << 1) + 1;
Mdr15 is not written forDevice so can skip all the compression stuff.
Have you seen an example with unicode. There seem to be too many
Hi Gerd
Did the '5' nibble in byte 2 indicate the size of lookup table? if so,
could reduce the table size so it overflows. I assume that setting byte
3 to <= table size didn't work
Ticker
On Thu, 2022-01-06 at 09:25 +, svn commit wrote:
> Version mkgmap-r4848 was committed by gerd on Thu,
Hi Gerd
On my eTrex 30x:
Same --lower-case map as before. Also loaded is GB map that is disabled
in Setup>Map; it uses same charset & sort, sort has same id1 but
different id2.
Where To? > Cities > Spell Search > "VOS" gives "No Results Found"
Spell Search has option to change the keyboard
nn wrote:
> Hi Ticker,
>
> OK, maybe you find more on that.
> BTW: Voßberg is very special as it probably also influences the MDR 17
> content.
>
> I think I'll merge the faster-mp branch into trunk this afternoon and
> continue on
> the Huffman encoding later.
>
>
4 | 04 | 01 00 | id2 1
> 0046 | 06 | e4 04 | codepage 1252
>
> Maybe I should repeat those tests with the mdr2 branch?
>
> Gerd
>
>
>
>
>
> Von: mkgmap-dev im Auftrag
Petermann wrote:
> Hi Ticker,
>
> here it is.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 4. Januar 2022 11:20
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Error
9:17 +0000, Ticker Berkin wrote:
> Hi Gerd
>
> Yes, this seemed to be the result of a bit of code where someone was
> starting to look at showing expansions and then stopped. The
> information in this list is shown more clearly while it is being read
> in the SRT 4 Character ta
Hi Gerd
Sorry - I hadn't noticed these changes. They don't show up with
$ svn log resources/sort/cp1252.txt or cp1254.txt
All the other mkgmap sort files have all the expansions possible
including the eszett and diphthongs if applicable.
The two non-mkgmap sort files (848.SRT/Turkey and
ow it works. if name is set to anything, what will {name
> '$
> {name}'} actually do?
>
> add and set are described in the style manual, but not the case
> without add or
> set (or i don't understand where to look for it).
>
>
> Regards
> Karl
>
>
> On s
Hi Karl
I suspect this won't work directly, the ":" you want to look for is
being taken as the operator. Maybe you can subst it first
name='{name|subst:":=>#"|part:"#:-1"}'
Ticker
On Sun, 2022-01-02 at 19:58 +0100, 7770 wrote:
> Hi.
>
> On page 16 and 17 in the styles manual the part
Hi Karl
1. include inc/name processing happens at the point of inclusion
2. I don't think variable expansion works within the context of filter
parameters - your difficulties suggest it really doesn't.
3. {set name= ... probably works correctly, but it is the
{name ...} statement that sets
Hi Gerd
In the resource/sort/cp*.txt sort definitions, I notices that all but
cp1252.txt/Western European and cp65001.txt/unicode don't handle "#"
correctly and cp1252.txt/Western European and cp1254.txt/Turkish don't
add expansions for all their double-characters.
Patch attached that fixes
and that will fail.
> I guess that Garmin produces an empty level in that case...
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Freitag, 31. Dezember 2021 10:57
> An: mkgmap development
> Bet
Hi all style users
I've noticed that the code and style manual differ in the meaning of
the highway-symbol max-length parameters.
The manual says the text is truncated to this length.
In the code: if the text is longer than the length it is left
untouched. No shield is added, spaces are not
Hi Gerd
Some thoughts on this:
Dividing the \0 count by some factor between 3 and 6 should reduce the
overall length of the strings. This is because there will be 0..7 bits
free after each string
To make the canonical tree: after using the standard algo to make a
normal tree, just remember the
Hi Gerd
Sorry about that - had been copy strange chars but it wasn't
from here! The Oracle java documentation has this character between:
int offsetByCodePoints
and
(int index, int codePointOffset)
Ticker
On Thu, 2021-12-30 at 15:26 +, Gerd Petermann wrote:
> Hi Ticker,
>
> please
others will cause problems. There might just be a few str.length() and
str.charAt() or other indexing that might need attention but this would
require a lot more searching. I've left the handling for
MALFORMED_INPUT so these shouldn't matter.
Ticker
On Wed, 2021-12-29 at 09:16 +, Ticker Berkin
Hi Gerd
Some of the old maps don't have Mdr sections after 19 and 29. Also some
code didn't spot it should test after Mdr19, so Summary, Display and
Check could give errors. I've added logic to stop getting sections
after all the header lengths I've found in the various samples.
Patch attached.
Hi Nick
Thanks.
Interesting, but not maybe not relevant to the Huffman stuff, in
mdr16austria.txt the MDR headers go out of sync after MDR30
Ticker
On Tue, 2021-12-28 at 18:28 +, nick wrote:
> Hi Gerd
>
> OK thanks will check that tomorrow.
>
> I think it's amazing how far both of you
Hi Arndt
As a matter of interest, does any text show for
https://www.openstreetmap.org/node/9122388694
or
https://www.openstreetmap.org/node/9115233473
The text is mostly 'Old Hungarian' and I wonder if the java encoder
tries any transliteration. What code-page are you using?
Ticker
On Tue,
Hi Gerd
I'll look at this sometime. I while ago I found something in one of the
MDR sections (probably the short strings) that handled something like
this.
Ticker
On Tue, 2021-12-28 at 13:22 +, Gerd Petermann wrote:
> Hi Ticker,
>
> okay, maybe you find time to implement a better
Hi Gerd
I'm working through your codebook discoveries but finding the patches
hard to undo/redo with other changes happening to display. I'd much
prefer you just committing all display changes as you go and I'll
update. I doubt if this will inconvenience anyone else at the moment.
Thanks
Ticker
_________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 27. Dezember 2021 20:06
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] r4836 stops Hungary & Romania
>
> Looks like uft16 surrogate pair chars are being separated by t
be used to
> find the correct entry
> in the byte array with the characters.
>
> So, maybe the stat value should be shifted to the right to make some
> sense.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
Looks like uft16 surrogate pair chars are being separated by the
substr.
Ticker
On Mon, 2021-12-27 at 19:28 +0100, Arndt Röhrig wrote:
> ...mayby is in the osm data a kryptic text like this:
>
> https://www.openstreetmap.org/node/9115233473
>
his patch.
>
> So, besides the fields with ??? the only open question is the meaning
> of the struct bytes in the first table.
> I guess it will become clear when I try to use the lookup table in
> the decoder.
>
> Gerd
>
>
> ________
>
Hi Gerd
I guessed that it was the \0 that cut the file off.
You mean something like answer 5 here:
https://stackoverflow.com/questions/759707/efficient-way-of-storing-huffman-tree
I looked at this earlier trying to work out if it was relevant but
didn't make it fit - I should have tried
Hi Gerd
Can you send me the Mdr16 display of some of the other maps you've been
looking at. I'd like to try and find some meaning for bytes 0..2 and
the prefix before the level 5 data.
Thanks
Ticker
On Wed, 2021-12-22 at 08:43 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I also thought that
Hi Gerd
That's great.
I don't have any maps with compression/Mdr16 or Mdr30-3.
http://gis.19327.n8.nabble.com no longer seems to work for me.
I found possible links to maps at:
http://www.garniak.pl/viewtopic.php?f=9=398
but interesting links were dead or went to generic page.
I suspect the
1-12-20 at 09:18 +, Gerd Petermann wrote:
> Hi Ticker,
> please explain. What counters do you see? What do they mean?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag von
> Ticker Berkin
> Gesendet: Montag, 20. Dezember 2021 09:49
&g
at the 1-bits might represent
> the position of leafs, but
> the bit counts don't match.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Sonntag, 19. Dezember 2021 10:12
> An: Development list for mkg
Hi Gerd
It looks like the order of the letter patterns approaches canonical
Huffman (but not quite as far as I can see). With this, only the number
of codes of each length is required to form the tree.
The "struct for {level}" looks like 2 numbers. Both increasing as
levels go from 20 to 6. The
Hi Gerd
I'm amazed at how they've made something that could be simple and
expressed with a few byte of control, around 140 bits for tree
structure and 80 or so bytes of characters so big and complex!
Maybe the few (5) layers closest to the root somehow hard coded.
Where a node has a sub-tree on
level depth 19
> ...
> write values at level depth 6
>
> This decribes all bytes in MDR 16 from offset 5c to the end.
>
> No idea yet what the prefixes mean.
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker
Hi Gerd
I found similar/same algos. I'm trying to thing of other ways that
might come up with what we see. I'll continue research.
Ticker
On Wed, 2021-12-15 at 20:18 +, Gerd Petermann wrote:
> Hi Ticker,
>
> do you have a link for me? None of the methods to store the tree that
> I found
and 32/33
> are common suffixes in road names.
> I doubt that this is related to the Huffman encoding. Maybe the code
> ""
> simply represents a special character that is replaced with a
> corresponding string in 30/31?
>
> No idea how that
Hi Gerd
Do you think there might be some form of escape sequence that is
followed by a ref to the clear road names in Mdr 30..33. I noticed when
looking at MapInstall manipulated Mdr that the '#' sort got changed.
Ticker
On Wed, 2021-12-15 at 11:13 +, Gerd Petermann wrote:
> Hi Ticker,
>
>
Hi Gerd
I was wondering if you have and can send me the SRT subfile from the
TOPO map you are looking at for the compression. In the Turkish map the
bits that seemed to be for selecting the correct variation of each
expansion character made little sense.
Thanks
Ticker
Hi Gerd
Do you fill in all the empty leaves with noticeable characters and
report them so you can spot patterns that haven't been defined and
their usage.
There seem to be some chars missing still (qwxy23). I don't know if the
shields/thin/fat separators make it into Mdr15
Ticker
On Tue,
Hi Gerd
Just got back to looking for some more. In addition I have:
000(space)
B 001001
D 00111
I 11001
P 001000
U 000111
V 01010
but you've probably got much further anyway
Thinking of various algos to represent the tree and considering what
they would make of the example Mdr16 data I
Hi Gerd
I was wondering if something like this could be done.
Do you mean bits are read right/low to left/high, effectively reversing
as it reads or is this the way the BitReader/Writer class works?
Assuming bits in natural order, 0111 does look like the string
terminator as it occurs at end,
t; fixed record size 12
> number of records 26,00
> implied size=312 (0x138)
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 13. Dezember 2021 15:50
> An: Development list for
| MDR 16 record size d4
> | | Number of records 1
> 00f2 | 00 00 00 00 | MDR 16 header flags
> | |
>
> Gerd
>
> ________
> Von: mkgmap-dev im
Hi Gerd
>From your example map, can you determine what settings should be used
for hasRecSize and hasMagic (MdrDisplay ~line 1351 and other modules as
well). I'd have expected (false, ?);
Ticker
On Mon, 2021-12-13 at 11:33 +, svn commit wrote:
> Version display-r572 was committed by gerd
he download link to the adria map
> somewhere
> in the archive, my downloaded file is called "AdriaTOPO 2.40 HR.exe"
> Unfortunately my links to Nabble no longer work.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berk
Hi Gerd
Does Mdr16 look like some form of a flattened Huffman tree? A common
representation is a stream of bits describing the shape and a stream of
chars giving the contents.
If you send me an example + the little bit at the start of Mdr15 you've
been using I'll have a look.
Ticker
On Sun,
Hi Gerd
I don't have any problem with it
Ticker
On Mon, 2021-12-13 at 09:02 +, Gerd Petermann wrote:
> Hi all,
>
> I got no feedback on the patch label_len170.patch. Any comments?
>
> Gerd
___
mkgmap-dev mailing list
Hi Gerd
Yes, this seemed to be the result of a bit of code where someone was
starting to look at showing expansions and then stopped. The
information in this list is shown more clearly while it is being read
in the SRT 4 Character table.
Ticker
On Mon, 2021-12-13 at 09:00 +, Gerd Petermann
Hi Gerd
In the example with the compressed strings, did it have Mdr30/31 and/or
Mdr32/33?
Ticker
On Sun, 2021-12-12 at 11:07 +, Gerd Petermann wrote:
> Hi all,
>
> for now I've added a check to stop if the MDR subfile gets > 2G.
> My findings reg. string compression in MDR 15:
> If Mdr15
ted *.srt.
> The original link to the turkey download posted here no longer works:
> https://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q2/026715.html
>
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Ges
w which one is better.
> I think the summary cannot be used as input for mkgmap because it
> contains several '?' where characters coulnd't be converted to
> unicode.
> (same problem when I create a map with --codepage=1252 and use
> SrtDisplay on that.
>
> Gerd
>
&
Hi Gerd
The alternative would be to use test.display.SrtDisplay to generate a
different version of our resources/sort/cp1254.txt that matches
theirs, or maybe have versions findable by id1/id2 that match.
Ticker
On Thu, 2021-12-09 at 09:09 +, Gerd Petermann wrote:
> Hi devs,
>
> I think
Hi Gerd
It seems reasonably close to what CommonDisplay does, and without
changing all the System.out.print/format, seems the best solution.
Ticker
On Wed, 2021-12-08 at 11:28 +, Gerd Petermann wrote:
> Hi devs,
>
> the display programs (MdrDisplay, NetDisplay, ...) show Chinese
>
ummary before...
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 8. Dezember 2021 11:12
> An: mkgmap development
> Betreff: [mkgmap-dev] Minor Display changes
>
> Hi Gerd
>
> I've ha
Hi Gerd
I've had a few minor display changes sitting around, mainly MdrSummary
+ something to reduce noise from reverse route calcs being slightly
different.
patch attached.
Following your last commit I don't get any lint warnings.
Ticker
Index: src/test/check/NodCheck.java
does make sense to show on the
> map, but
> given your explenation i will keep it in my style only.
>
>
> Regards
> Karl
>
>
> On fredag 3 december 2021 11:30:44 CET Ticker Berkin wrote:
> > Hi
> >
> > When the emergency phone issue cropped
bly better to throw an exception in
> setStrength()?
>
> Gerd
>
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Freitag, 3. Dezember 2021 11:39
> An: mkgmap-dev@lists.mkgmap.org.uk; mkgmap-...@lists.mkgmap.org.u
> 0 X 2E19 PHOTOGRAPHIC SUPPLIES
> 0 X 2E1A WORLD FURNITURE
> 0 X 2E1B OPTICIAN
>
> Depending on device some may not be searchable.
>
> r
>
> Nick
>
> On 03/12/2021 10:41, Ticker Berkin wrote:
> > Hi all
> >
> > I have no problem with getting rid
Hi all
I have no problem with getting rid of tags where there are no usages in
OSM.
It is best to use 0x2e00 for other/unknown/etc rather than 0x2e0c which
was at the end of the list on old devices and showed as 'other'.
My newer device has:
0x2e0c Speciality Retail (also 0x2e0a)
0x2e0d
Hi Gerd
Beware that the sort with keys (as used in all of Mdr) only sorts to
the TERTIARY level, so doing a IDENTICAL scan (either with collator or
.equals()) can give strange results as IDENTICAL entries might not be
adjacent.
Ticker
On Fri, 2021-12-03 at 10:04 +, svn commit wrote:
>
Hi
When the emergency phone issue cropped up earlier in the year I removed
amenity=emergency_phone from my style but decided not to add
emergency=phone because there are lots and lots of them with very
specific purposes, totally relevant to the location, probably visible
or signed at the point of
Hi Gerd
Our unicode sort is known to be incomplete and this incompleteness is
probably reflected in the SRT subfile. MapSource might try and use this
to effectively reproduce the Mdr section we don't write for unicode and
this could make lots of names look identical and hence not to be shown
in
Hi Gerd
I don't understand either why CommonHeader change caused problem.
There is a slight difference in the handling of
String(xx, "charSetName")
and
String(xx, actualCharSet)
in that the second replaces unmapable chars and won't throw an
exception.
Ticker
On Wed, 2021-12-01 at 11:37
Hi Gerd
Something here upsets a bunch of tests.
Ticker
On Tue, 2021-11-30 at 15:34 +, svn commit wrote:
> Version mkgmap-r4822 was committed by gerd on Tue, 30 Nov 2021
>
> - use StandardCharsets.US_ASCII instead of "ascii" parameter where
> possible
> - stop with error when --code-page
be the combination never works well. Needs more testing.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 30. November 2021 12:15
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] F
Hi Gerd
Building a map with --code-page=0 --index --gmapsupp --gmapi
(exactly same behaviour without --code-page=0)
Then, using raw mode editor to look at various components.
The LBL section of tiles, gmapsupp.img and gmapi looks encoded - I
can't find any recognisable strings.
However, the
Hi Gerd
Please ignore previous patch - I hadn't saved deletion of other changes
Attached is good version
Sorry about that
Ticker
Index: doc/options.txt
===
--- doc/options.txt (revision 4819)
+++ doc/options.txt (working copy)
@@
explanation for length differences
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 29. November 2021 10:15
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Format6Encoder/Decoder
>
> Hi Gerd
>
> Y
ast with
> Garmin software.
>
> Attached is my proposed fix if you still think --lower-case should be
> supported with codepage 0
>
> Gerd
>
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Freitag, 2
> Gerd
>
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Samstag, 27. November 2021 11:23
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Small problem with global index
>
> Hi Gerd
>
> m
.
>
> I prefer a patch that changes mkgmap to produce the same index as
> MapSource.
>
> I hope I've done nothing wrong during testing. Do you get other
> results?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Be
Hi Gerd
Patch attached that defaults Format6Encoder transliterator to UPPER.
mkgmap unconditionally calls to set required mode but test environment
doesn't.
Ticker
On Fri, 2021-11-26 at 18:40 +, Gerd Petermann wrote:
> Hi Ticker,
>
> result looks ok, but unit test CodeFunctionsTest fails.
Hi Gerd
I was looking at encoders and noticed obvious mistake in Format6Decoder
relating to lower-case, plus parts that can be simplified to be general
and consistent with Format6Encoder.
Format6Encoder can handle a bunch of other characters (the remains of
the 'ascii' printables) + lower-case -
Hi Gerd
I was sort of thinking the opposite. PlaceFile using some method (eg
what it does) to dedupe city/region/country and this is extended to the
POI/MDRBuilder logic, such that combinations of these 3 have unique
sets of index values regardless of case.
Then the relevant MdrX sections should
an confirm that the
> search for "Baybridge Lane" doesn't work as expected.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 24. November 2021 18:58
> An: Development list for mkgmap
&
Hi Gerd
In this example, choosing the correct version of the spelling doesn't
necessarily work!
To find "Alma Lane", which is in Upton=wherWell, "wherWell" must be
selected as the city.
To find "Baybridge Lane", also in Upton=wherWell, "Wherwell" must be
given.
Getting capitalisation
Hi Gerd
The default inc/address rules are not very good for UK towns and
smaller - need to start from mkgmap:admin_level10. Appropriate change
is in tstStyle.zip
Nothing significant to this has changed in bounds.zip - I'm using a
version from April 2021
Ticker
On Wed, 2021-11-24 at 15:40
Hi Gerd
Here it is
Ticker
On Wed, 2021-11-24 at 14:57 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I (my tools) don't know how to use default.diff. Please can you
> either create a normal svn diff or zip the complete style?
>
> Gerd
<>
___
Hi Karl
What code-page are you using for this. "ł" from Małopolska is unicode
U+0142 LATIN SMALL LETTER L WITH STROKE and isn't representable in
cp1252, but is in cp1250 and unicode/cp65001
Ticker
On Tue, 2021-11-23 at 08:08 +, Gerd Petermann wrote:
> Hi Karl,
>
> maybe you have different
Wherwell
Chant Close Wherwell Wherwell
Bigpath LaneUpton Either as crosses tile
Church Street BothEither, finds expected one
Ticker
On Tue, 2021-11-23 at 11:03 +, Ticker Berkin wrote:
> Hi Gerd
>
> I'm not ignoring this, but trying to
Hi Gerd
I'm not ignoring this, but trying to put the essence of my renames into
the default style and testing with a r4810 and --lower-case I find
MapSource isn't giving me a Find > Address option and BaseCamp doesn't
find any streets and once said "Doesn't support Address Search"
So I'll try
Hi Gerd
How did you get a Mdr3?
I've been using MapInstall then running various display modes on the
gmapsupp and MdrSummary reports
initial values72e
MDR 1 NR=2 (02) RS=4 magic=0x0
MDR 4 NR=117 (75) RS=3 magic=0x0
MDR 5 NR=17164 (00430c) RS=8 magic=0x151
MDR 6
ticed such a problem in MapSource. Where do
> you see this problem?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 22. November 2021 12:36
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-
use --lower-case in Germany are road names like
> Hauptstraße which is displayed as Hauptstrasse without that option.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 22. November 2021 11:43
&
Hi Gerd
The first stages of investigation should avoid other complexities that
might be introduced by --lower-case (and --unicode). In this
environment there should be no difference between SECONDARY and
TERTIARY so the question is reduced to .equals() vs .compare() and
other flag settings / Mdr
is possible that MapInstall, having access to all the case variants
via the LBL section, might rebuild a case-sensitive index.
Was hoping to get mdrUnicode_v9p.patch out of the way before this.
Ticker
On Sat, 2021-11-20 at 17:27 +0000, Ticker Berkin wrote:
> Hi Gerd
>
> I can't look at this in
Hi Gerd
I can't look at this in detail at the moment but:
Lower case and indexing behaviour is affected by the tile processing
stages deduping using upper case on country/region/city when loading
MDR data (mainly from mkgmap:country/region/city). I seem to remember
that explicit city POI behave
Hi Gerd
Please ignore the CodeFunctions.java change in this patch.
A better / hybrid TableTranslitorator is needed before
SparseTranslitorator can go.
Ticker
On Thu, 2021-11-18 at 17:47 +, Ticker Berkin wrote:
> Hi Gerd
>
> For any code-page except Japanese/cp932, AnyCharS
Hi Gerd
For any code-page except Japanese/cp932, AnyCharSetEncoder takes
anything that can't be represented, tries to find a reasonable ascii
representation or "?", then writes this to the output. This is a big
assumption for far-eastern charsets, most likely generating garbage
with possible
erd
>
> ____
> Von: mkgmap-dev im Auftrag von
> Ticker Berkin
> Gesendet: Donnerstag, 18. November 2021 15:37
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4811: fix
> java.lang.AssertionError while building
Hi Gerd
Sort and Collator with lots of ignored characters did it for me.
The new assert in Mdr29 is there to detect problems before the getting
to the stage where Mdr25 ptr needs more bytes than Mdr5 ptr.
Ticker
On Thu, 2021-11-18 at 14:28 +, Gerd Petermann wrote:
> Hi Ticker,
>
> anyhow,
Hi Gerd
I hadn't thought of that!
Ticker
On Thu, 2021-11-18 at 13:42 +, Gerd Petermann wrote:
> Hi Ticker,
>
> If I got that right the result of the MdrCheck depends on the
> mkgmap.jar.
> This is a bit tricky when comparing the results. I'll use the patched
> binary for now.
>
> Gerd
.
Ticker
On Thu, 2021-11-18 at 09:21 +, Gerd Petermann wrote:
> Hi Ticker,
>
> please share your testdata so that I'm able to reproduce the
> differences.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berk
for anything in
Unicode with no/0 sortOrder.
With this patch it becomes possible for Unicode to trigger the original
problem again. Attached is mdrUnicode_v9b.patch that has the fix for
this from the previous patch.
Ticker
On Tue, 2021-11-09 at 18:13 +, Ticker Berkin wrote:
> Hi Gerd
dling of unmapped chars.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 17. November 2021 17:35
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] New assertion, now with code-page=632 and
> Japan tile
____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 17. November 2021 15:37
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] New assertion, now with code-page=632 and
> Japan tile
>
> Hi Gerd
>
> My description didn't qui
Hi Gerd
My description didn't quite mean what I hoped it did - sorry. I was
thinking that there would be a single attempt at encoding the whole
string, and if that fails, start again but char-by-char.
But, assuming result.length() works and charBuffer.get() and
outBuff.put() maintain positions
r that contains
> "１２３７−１" instead of "1237-1".
> https://www.fontspace.com/unicode/analyzer#e=77yR77yS77yT77yX4oiS77yR
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 15. November 2021
25 logic
>
> Hi Ticker,
>
> I didn't notice that the Mdr25 is the same. In that case it is really
> no help.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 15. November 2021 20:17
> An: Dev
101 - 200 of 1100 matches
Mail list logo
