I'm looking at coordinate pairs defining Australian maritime boundaries. From here.

The coordinate pairs look like this:

AUS-CS-24 14°05¢09.4168²S 156°38¢26.5411²E ITRF2000

AUS-CS-25 14°05¢16.2817²S 156°38¢56.5798²E ITRF2000

My questions is what does the "¢" mean in the context of coordinate data? Also why is there a "²" at the end?

  • 10
    Geographic coordinates are often expressed in degrees, minutes and seconds, like: 14°05'09.5168". It is only a guess, but perhaps the source of your coordinates text was unable to interpret some unicode version of smart-quotes, and instead of displaying them as quote marks, just displayed whatever characters were set for the text encoding that it was using (ASCII?). What is the source and linneage of the data? Jan 11, 2021 at 1:18
  • 4
    It seems an issue in PDF encoding on the website, so ¢ is single quote & ² is double quotes.
    – Shiko
    Jan 11, 2021 at 1:28
  • 4
    if you search ¢ in the pdf it highlights the minutes [']
    – Mapperz
    Jan 11, 2021 at 4:42
  • 3
    Evince will happily find °, but not ¢ in those PDFs. Seems to be a technical problem of the tool used to generate them.
    – mcarton
    Jan 11, 2021 at 10:04
  • 1
    @Son of a Beach - typo, should be "lineage" ;-) Jan 11, 2021 at 11:57

2 Answers 2


Your viewer, or the website, has some problem with the fonts. Perhaps your browser does not get access to the defined fonts. Works for me, though, and this is how it should look:

enter image description here

Coordinates are expressed as degrees, minutes, and seconds. Try the file downloads https://www.legislation.gov.au/Details/F2012L01081/Download.


I have the same issue than you with Firefox. Chrome and Edge show correct characters for minutes and seconds.


It seems to be a problem with the website, and the intended rendering should be using the usual degrees, minutes and seconds symbols: °, , and . As noted by other users, different browsers and PDF readers behave differently.

If you look at the website's header, you can see that it explicitly claims that the page is UTF-8:

$ curl -v 'https://www.legislation.gov.au/Details/F2012L01081' 2>&1 | grep Content-Type
< Content-Type: text/html; charset=utf-8
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />[…]

but instead of using the proper Unicode characters for minute and second, the website uses those characters you see and attempts to change their font to a "Symbol" font:

<p class=TableText>25°55<span style='font-family:Symbol'>¢</span>50.8665<span   style='font-family:Symbol'>²</span>S</p>

The font picked by your browser does not render those symbols as , and . As noted by other users, different tools have different support for this. In my case both Firefox and Chrome render the characters improperly. I do not have that font on my system. Other users report that Chrome rendered it as expected. My PDF reader both properly renders the font as expected and its search tool seem to be aware of the font because searching for finds the expected characters, while other users report that they need to search for ¢.

The "Symbol" font seems to be a legacy from the pre-Unicode area, as Wikipedia notes:

Full legacy support of the Symbol font is provided by major modern web browsers like Internet Explorer and Google Chrome. That support involves a specific handling of Adobe's special encoding, which is not properly implemented in at least some versions of other browsers, including Opera, Safari and Firefox.

As can also be seen on Wikipedia, this font maps the , and characters to the value 0xA2 and 0xB2 respectively. In UTF-8 (that the page claims to be using), those values are continuation characters and should never appear on their own. Web browsers are usually very lenient when it comes to such errors and will try to correct them somehow. In this case it seems your browser falls back to ISO/IEC 8859 (another common encoding with partial compatibility with UTF-8) of which some parts map the values 0xA2 and 0xB2 to ¢ and ² respectively.

  • I can replicate this in both Firefox 84 and Chromium 87 on Ubuntu 18.04; like you I don't have "symbol". But claiming to be UTF-8 and calling for a symbol font is just daft, especially as the ASCII character set provides a perfect usable fallback. I suspect at some point the table was saved as html from Word, having previously been made to look nice. (changing the user agent of course doesn't help as the page is serving up nonsense whatever the browser)
    – Chris H
    Jan 11, 2021 at 11:57
  • Especially since the degree symbol is used without any hesitation or workarounds.
    – chepner
    Jan 11, 2021 at 15:22
  • 1
    This is a good answer but the last paragraph is wrong. In the page, the glyphs are represented by the code points U+00A2 and U+00B2, encoded in UTF-8 as C2A2 and C2B2, not by invalid continuation bytes. In effect the Symbol font uses peculiar glyphs for those code points that look nothing like how Unicode says they're supposed to look. In reality it may be that the browser is mapping the code points to U+2032 and U+2033 with an internal table and then using a font with more sensible Unicode mappings.
    – benrg
    Jan 11, 2021 at 17:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.