Page 2 of 2

Re: Bad reading nooa monthly e yearly report

Posted: Thu 07 Nov 2019 1:07 pm
by mcrossley
The Saratoga template doesn't use UTF-8 encoding, so yes you have to manipulate the text like that to get it to display correctly. A UTF-8 encoded NOAA file embedded in a UTF-8 encoded HTML page <pre> displays just fine.

Re: Bad reading nooa monthly e yearly report

Posted: Thu 07 Nov 2019 1:14 pm
by beteljuice
Now't to do with the beteljuice.
The web page viewer simply wraps what is generated in <PRE> tags so that spaces / linefeeds are respected.

However Hans ... as you well know we are discovering an increasing amount of server / ftp combinations that are corrupting &deg; regardless of binary or ascii. (I think maybe something to do with binary 64 ?)

Although &deg; is one of the HTML5 preferred syntaxes, perhaps it should be replaced by whatever you finally found works for all ?

Re: Bad reading nooa monthly e yearly report

Posted: Thu 07 Nov 2019 2:55 pm
by HansR
@Mark: OK apparently everybody has to find his own solution. Maybe I just change the default Saratoga encoding :)
@beteljuice:
beteljuice wrote: Thu 07 Nov 2019 1:14 pm However Hans ... as you well know we are discovering an increasing amount of server / ftp combinations that are corrupting &deg; regardless of binary or ascii. (I think maybe something to do with binary 64 ?)
Maybe... but see my next remark... :?
beteljuice wrote: Thu 07 Nov 2019 1:14 pm Although &deg; is one of the HTML5 preferred syntaxes, perhaps it should be replaced by whatever you finally found works for all ?
That whatever I found, works for all is actually not one solution: in my situation for CumulusUtils it means that I use "&deg;C" for HTML (having tried &#186; &#x00B0; and making some errors there) and "\u00B0C" for generated javascript. So far this works for me everywhere. :groan:

Re: Bad reading nooa monthly e yearly report

Posted: Wed 13 Nov 2019 8:00 pm
by Nevizio
mcrossley wrote: Thu 07 Nov 2019 11:56 am
Nevizio wrote: Thu 07 Nov 2019 11:25 am Another question I noticed in the dashboard interface but also in gauge (below I posted the image with the red arrow indicating the maximum value shown) the maximum value of the wind speed is 40 Km / h, as you can 'change this value?
A can of worms!

Short answer yes, in gauges.js

Change "windScaleDefMaxKmh" to what ever you want. (line 119 in the interface version of gauges.js)

But the code will change the max value depending on the data it is given - it will automatically increase the value as the wind speed approaches the current max value - and and what numbers will give a nice spread of figures and tickmarks.

Hi , where do I find this file? I searched everywhere :roll: :?:

Re: Bad reading nooa monthly e yearly report

Posted: Tue 19 Nov 2019 10:51 pm
by Nevizio
I still have this strange character problem, I'd like to solve it, but how? :cry:
On the interface of cumulus mx I see well the file nooa on the web instead no.

in a simple way how is it solvable? :oops:

I send I upload the file to my server and on my site I have the link to the file that is natively a txt, as it remains on the web

Re: Bad reading nooa monthly e yearly report

Posted: Wed 20 Nov 2019 8:30 am
by HansR
Reading the text reports output from Cumulus it looks good. As @mcrossley remarks, the textfiles are apparently encoded UTF-8. I assume - because it works normally well - that a correct &deg; symbol would work.

It is apparently in the file wxnoaaclimatereports.php which includes include-noaa-reports.php. It seems to me, the last file does some filtering/transformation with the report generated by Cumulus[MX].

The last file contains many lines saying:

Code: Select all

$rpt = preg_replace('|°|Uis','&deg;',$rpt);
and in my humble opinion, somewhere there the problematic character is generated. The display of NOAA reports is created by Ken True with help from Beteljuice for Cumulus.

So, my guess is @Beteljuice may have an answer - as to why the character is here before the &deg; - and if he does not, we better move the question to the SaratogaWX board. Point is the &deg; is correctly there and displayed, but in the process the weird extra character is added before it. Where and how to remove it is up to the programmer(s).

Re: Bad reading nooa monthly e yearly report

Posted: Wed 20 Nov 2019 9:41 am
by mcrossley
HansR wrote: Wed 20 Nov 2019 8:30 am As @mcrossley remarks, the textfiles are apparently encoded UTF-8.
The encoding is optionally UTF-8 - it is a configuration option in the NOAA settings, if that is not selected it will be the users default encoding, normally Windows-1250 on Windows.

Re: Bad reading nooa monthly e yearly report

Posted: Wed 20 Nov 2019 10:37 am
by Nevizio
Another strange thing is that you have to send these files via extra web files because using the interface setting
noaa setting does not take place.

Re: Bad reading nooa monthly e yearly report

Posted: Wed 20 Nov 2019 11:19 am
by HansR
mcrossley wrote: Wed 20 Nov 2019 9:41 am
HansR wrote: Wed 20 Nov 2019 8:30 am As @mcrossley remarks, the textfiles are apparently encoded UTF-8.
The encoding is optionally UTF-8 - it is a configuration option in the NOAA settings, if that is not selected it will be the users default encoding, normally Windows-1250 on Windows.
Aha, switched that off. Never realised that, completely missed it.
Will report back tomorrow.

Re: Bad reading nooa monthly e yearly report

Posted: Thu 21 Nov 2019 5:05 am
by HansR
@Nevizio:
@mcrossley: indeed, Switch off UTF-8 encoding in the NOAA settings did it! :)