Encoding of the labels text in the DynamicLoading mode

I noticed another small malfunction in version 5.2.

I tried out the OgrLayer.DynamicLoading mode. And it works very well.
However, there are problems with the encoding of the text for signatures, if national encodings are used.
The layer is loaded from the PostgreSQL server, the encoding of the tables is UTF-8.
And if you use the normal mode, then there are no problems, everything works correctly.
I need the Russian font to be displayed correctly. However, I do not get exactly what I need.
And if I use DynamicLoading, then this is the picture:

This is a normal memory load

This is the modeDynamicLoading

I understand that the encoding here is CP-1251, not UTF-8

Hello Valeriy.

I’m sorry, but just for clarification; Is the only difference between these map renderings that one is loaded without Dynamic Loading, and the other is loaded using Dynamic Loading? All other code and data is the same?

I ask because you said that the encoding of the tables is UTF-8, but below the Dynamic Loading image, I think you are saying that the encoding is CP-1251, and not UTF-8.

OR are you saying that the reason the text is incorrect is that it is being interpreted as CP-1251 when it should instead be interpreted as UTF-8?

All OGR layers are loaded into memory-based Shapefiles in the OCX, and dynamically loaded layers use a deferred loading; and so I’m looking for areas in the code where the label fields are loaded to see if they are treated differently, and perhaps losing their proper encoding.

Thank you.

Hello Jerry.
Yes, the code is exactly the same. In the first case, I load the data as usual, and in the second case, I turn on the mode Dynamic Loading

Tables in the UTF-8 database. Well, I said about CP-1251… this is the text in the second picture in the form of incomprehensible hieroglyphs and I tried to find out its encoding to look through an online decoder. I set the Russian text (ГЭК Березка 8) in UTF-8 encoding and it turns out in CP-1251 - (ГЭК Березка 8). That is, exactly as in the screenshots. I don’t know if this information is superfluous… and maybe it will additionally help.
And it turns out that yes, instead of being UTF-8, it is displayed as CP-1251.
In any case, when you turn on the mode Dynamic Loading the text is displayed incorrectly. And if you turn it off, then everything works well.

That is helpful information. Thank you.

Hello Valeriy.

I’m sorry it took 3 weeks to get back to this, but I believe that I found the error. All strings loaded from an OGR datasource should be interpreted as UTF-8 (although there can be variances based on the Global Setting OgrStringEncoding, but that’s the exception rather than the rule).

When looking through the various places where strings are loaded, I found a case within the dynamic loader of OGR records that is interpreting the String fields as ANSI rather than UTF-8. I’m fairly confident that this is the error that you’ve identified.

I will have to write it up and submit a fix. If you build your own copy of the OCX, I can point to you the error and send you the fix (once I make the change). Otherwise, it will be in the next release.

Kind Regards,

UPDATE: Following is the change that I made, starting at Line 138 of file Ogr2RawData.cpp:

	else //if (type == OFTString )
		// string should be interpreted as UTF-8 unless overridden in Global Settings
		CStringW ws = OgrHelper::OgrString2Unicode(poFeature->GetFieldAsString(iFld));
		var->vt = VT_BSTR;
		var->bstrVal = W2BSTR(ws);

Hello Jerry.

Thanks a lot, I will compile the new version for myself according to these changes. I hope you will add the fix to GitHub.

With respect to you, Valeriy.

The GitHub code has now been updated with this fix. The associated ticket is MWGIS-238.

Thank you very much.