alphacocoa-devel Mailing List for AlphaCocoa (Page 7)

Status: Alpha

Brought to you by: bdesgraupes, jguyer, vincentdarley

alphacocoa-devel — AlphaCocoa Development List

You can subscribe to this list here.

2016	Jan	Feb	Mar (12)	Apr (19)	May (60)	Jun (77)	Jul (23)	Aug (8)	Sep (28)	Oct (16)	Nov (95)	Dec (56)
2017	Jan (127)	Feb (169)	Mar (59)	Apr (132)	May (27)	Jun	Jul (7)	Aug (1)	Sep (15)	Oct (12)	Nov (15)	Dec (17)
2018	Jan	Feb (2)	Mar (25)	Apr (19)	May (28)	Jun (75)	Jul (48)	Aug	Sep (31)	Oct (26)	Nov (51)	Dec (82)
2019	Jan (46)	Feb (7)	Mar (8)	Apr	May (9)	Jun (8)	Jul (21)	Aug (30)	Sep (9)	Oct (16)	Nov (14)	Dec (23)
2020	Jan	Feb (6)	Mar	Apr (7)	May (47)	Jun (12)	Jul (7)	Aug (5)	Sep (4)	Oct (24)	Nov (15)	Dec (14)
2021	Jan (6)	Feb (5)	Mar (20)	Apr (6)	May (46)	Jun (17)	Jul	Aug	Sep	Oct	Nov (2)	Dec
2022	Jan	Feb (1)	Mar	Apr (1)	May	Jun	Jul (2)	Aug	Sep (2)	Oct	Nov (1)	Dec
2023	Jan	Feb (1)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (8)	Nov	Dec
2024	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (2)
2025	Jan (3)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

Flat | Threaded

<< < 1 .. 5 6 7 8 9 .. 58 > >> (Page 7 of 58)

[Alphacocoa-devel] [alphacocoa:tickets] #240 Encoding

From: Bernard D. <bde...@us...> - 2020-11-20 13:26:34

Hi James,
thank you for the suggestion. The problem with the *file* command is that it is not sufficiently accurate and reliable. For instance, I tested it (with option `-I` to get a mime type) on a file encoded in macRoman and got:
`text/plain; charset=unknown-8bit`
I tested it on a file containing greek text written ISO-8859-7 and got :
`text/plain; charset=iso-8859-1` (sic, 8859-1, not 8859-7).
Same wrong result with a russian text in ISO8859-5.
I'm afraid this would lead to wrong decisions that would be quite frustrating for the user.

---

** [tickets:#240] Encoding**

**Status:** open
**Created:** Sat Oct 24, 2020 07:43 AM UTC by James Connolly
**Last Updated:** Sat Oct 24, 2020 07:46 AM UTC
**Owner:** nobody

Hello, first thanks for all the great work from a long term user (≈1997 on) !

A suggestion :Would it be possible to have a "Default encoding : Check file on open"?

This "check file on open" would, upon opening a file, have Alpha check the file's (e.g. BSD "file" command) and use that. And only then open the "Encodings popup" if this fails.

At present I have many files in ISO-8859 and the pop-up is working rather hard. And I'm not inclined to convert them all to UTF-8 in order to avoid further potential problems : if Alpha can handle ISO-8859, why not silently continue to do so where appropriate is my thinking.

Cheers, James

p.s. not files as "bug" nor "task" but as "RFE" which I hope means "suggestion".

---

Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Alphacocoa-devel] [alphacocoa:tickets] #241 Rectangular replace (copy/paste) fails

From: K.-M. S. <k-m...@us...> - 2020-11-11 12:42:35



---

** [tickets:#241] Rectangular replace (copy/paste) fails**

**Status:** open
**Created:** Wed Nov 11, 2020 12:42 PM UTC by K.-M. Schindler
**Last Updated:** Wed Nov 11, 2020 12:42 PM UTC
**Owner:** nobody


After a rectangular copy covering mutiple lines, the rectangular paste on another rectangular selection fails in so far as the paste is inserted at the first position with new lines for the rest of the copy. Example:
  AA  11  aa 111
  BB  22  bb 222
  CC  33  cc 333
  DD  44  dd 444
  EE  55  ee 555

Rectangular selecting bb and cc and copy and pasting to the rectangular selection of CC and DD yields:

  AA  11  aa 111
  BB  22  bb 222
  bb
cc  33  cc 333
    44  dd 444
  EE  55  ee 555

Note that the correct parts are deleted, but the insert fails maybe due to a wrong interpretation of the separation of the parts. I also had a look whether it results from some settings, but could not find anything.


---

Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Alphacocoa-devel] [alphacocoa:tickets] #240 Encoding

From: James C. <jpg...@us...> - 2020-10-24 07:46:17

p.s. to be extra clear : I don't want to change the file open pref. to default to "ISO-8859" either, since this would introduce popups for UTF-8 files I open instead.



---

** [tickets:#240] Encoding**

**Status:** open
**Created:** Sat Oct 24, 2020 07:43 AM UTC by James Connolly
**Last Updated:** Sat Oct 24, 2020 07:43 AM UTC
**Owner:** nobody


Hello, first thanks for all the great work from a long term user (≈1997 on) !

A suggestion :Would it be possible to have a "Default encoding : Check file on open"?

This "check file on open" would, upon opening a file, have Alpha check the file's (e.g. BSD "file" command) and use that. And only then open the "Encodings popup" if this fails.

At present I have many files in ISO-8859 and the pop-up is working rather hard. And I'm not inclined to convert them all to UTF-8 in order to avoid further potential problems : if Alpha can handle ISO-8859, why not silently continue to do so where appropriate is my thinking.

Cheers, James

p.s. not files as "bug" nor "task" but as "RFE" which I hope means "suggestion".



---

Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Alphacocoa-devel] [alphacocoa:tickets] #240 Encoding

From: James C. <jpg...@us...> - 2020-10-24 07:43:51



---

** [tickets:#240] Encoding**

**Status:** open
**Created:** Sat Oct 24, 2020 07:43 AM UTC by James Connolly
**Last Updated:** Sat Oct 24, 2020 07:43 AM UTC
**Owner:** nobody


Hello, first thanks for all the great work from a long term user (≈1997 on) !

A suggestion :Would it be possible to have a "Default encoding : Check file on open"?

This "check file on open" would, upon opening a file, have Alpha check the file's (e.g. BSD "file" command) and use that. And only then open the "Encodings popup" if this fails.

At present I have many files in ISO-8859 and the pop-up is working rather hard. And I'm not inclined to convert them all to UTF-8 in order to avoid further potential problems : if Alpha can handle ISO-8859, why not silently continue to do so where appropriate is my thinking.

Cheers, James

p.s. not files as "bug" nor "task" but as "RFE" which I hope means "suggestion".



---

Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

Re: [Alphacocoa-devel] Alpha Release 9.2.1 (Gianfar-2)

From: Eberhard W L. <el...@li...> - 2020-10-23 08:01:27

take your time

el

—
Sent from Dr Lisse’s iPad Mini 5
On 23. Oct 2020, 09:41 +0200, Bernard Desgraupes <bde...@or...>, wrote:
> Hi Eberhard,
>
> unfortunately no :-(
>
> I’ll look into it now.
>
> Bernard
>
>
> > Le 23 oct. 2020 à 09:22, Dr Eberhard W Lisse <el...@li...> a écrit :
> >
> > Bernard,
> >
> > does it fix my email issue?
> >
> > el
> >
> > On 2020-10-23 08:57 , Bernard Desgraupes wrote:
> > > Hi all,
> > >
> > > I'm pleased to announce the release of Alpha 9.2.1 ("Gianfar-2
> > > <https://alphacocoa.sourceforge.io/AlphaStar.html>") for Mac OS X 10.11
> > > or greater (El Capitan, Sierra, High Sierra, Mojave, Catalina).
> > >
> > > This is a minor technical update that fixes recent issues found in 9.2.
> > > See below.
> > >
> > [...]
> >
> >
> > --
> > Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist
> > el...@li... / * | Telephone: +264 81 124 6733 (cell)
> > PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP
> > 10007, Namibia ;____/ Sect 20 of Act No. 4 of 2019 may apply
> >
> >
> > _______________________________________________
> > AlphaTcl-users mailing list
> > Alp...@li...
> > http://lists.sourceforge.net/lists/listinfo/alphatcl-users

Re: [Alphacocoa-devel] Alpha Release 9.2.1 (Gianfar-2)

From: Bernard D. <bde...@or...> - 2020-10-23 07:41:49

Hi Eberhard,

unfortunately no :-(

I’ll look into it now.

Bernard


> Le 23 oct. 2020 à 09:22, Dr Eberhard W Lisse <el...@li...> a écrit :
> 
> Bernard,
> 
> does it fix my email issue?
> 
> el
> 
> On 2020-10-23 08:57 , Bernard Desgraupes wrote:
>> Hi all,
>> 
>>  I'm pleased to announce the release of Alpha 9.2.1 ("Gianfar-2
>> <https://alphacocoa.sourceforge.io/AlphaStar.html>") for Mac OS X 10.11
>> or greater (El Capitan, Sierra, High Sierra, Mojave, Catalina).
>> 
>> This is a minor technical update that fixes recent issues found in 9.2.
>> See below.
>> 
> [...]
> 
> 
> -- 
> Dr. Eberhard W. Lisse   \         /       Obstetrician & Gynaecologist
> el...@li...             / *      |  Telephone: +264 81 124 6733 (cell)
> PO Box 8421 Bachbrecht  \      /  If this email is signed with GPG/PGP
> 10007, Namibia           ;____/ Sect 20 of Act No. 4 of 2019 may apply
> 
> 
> _______________________________________________
> AlphaTcl-users mailing list
> Alp...@li...
> http://lists.sourceforge.net/lists/listinfo/alphatcl-users

Re: [Alphacocoa-devel] Alpha Release 9.2.1 (Gianfar-2)

From: Dr E. W L. <el...@li...> - 2020-10-23 07:22:48

Bernard,

does it fix my email issue?

el

On 2020-10-23 08:57 , Bernard Desgraupes wrote:
> Hi all,
> 
>  I'm pleased to announce the release of Alpha 9.2.1 ("Gianfar-2
> <https://alphacocoa.sourceforge.io/AlphaStar.html>") for Mac OS X 10.11
> or greater (El Capitan, Sierra, High Sierra, Mojave, Catalina).
> 
> This is a minor technical update that fixes recent issues found in 9.2.
> See below.
> 
[...]


-- 
Dr. Eberhard W. Lisse   \         /       Obstetrician & Gynaecologist
el...@li...             / *      |  Telephone: +264 81 124 6733 (cell)
PO Box 8421 Bachbrecht  \      /  If this email is signed with GPG/PGP
10007, Namibia           ;____/ Sect 20 of Act No. 4 of 2019 may apply

[Alphacocoa-devel] Alpha Release 9.2.1 (Gianfar-2)

From: Bernard D. <bde...@or...> - 2020-10-23 06:58:13

Hi all,

I'm pleased to announce the release of Alpha 9.2.1 ("Gianfar-2 <https://alphacocoa.sourceforge.io/AlphaStar.html>") for Mac OS X 10.11 or greater (El Capitan, Sierra, High Sierra, Mojave, Catalina).

This is a minor technical update that fixes recent issues found in 9.2. See below.

Beware: the Maverick (10.9) and Yosemite (10.10) versions of OS X are no longer supported. The latest version of Alpha running on these two systems is 9.0.3.

Here is the URL to download the disk image:
https://sourceforge.net/projects/alphacocoa/files/9.2.1/Alpha_9.2.1.dmg.zip/download <https://sourceforge.net/projects/alphacocoa/files/9.2.1/Alpha_9.2.1.dmg.zip/download> (32.68M)

The MD5 checksum is: d1112d656e69e03063f51ed5da171cb6
The SHA1 checksum is: 48b7c7454403ba2f45c011b8b77c7e72b71aabb1
The RMD160 checksum is: 808d33483c547aa65fb0358576e06746cb60ba5d
The SHA256 checksum is: 863f1a4c59f69cc2f7735356783bac2151449b1b3bb1c1977d73fb1f210478b1

If you find problems with the application, don't hesitate to post bug reports. They are essential to keep track of the deficiencies. See Alpha's Bug Tracker <https://sourceforge.net/p/alphacocoa/tickets/>.

Thank you for using Alpha.
Cheers,
Bernard
<>Changes from previous version

This is a minor technical update for version 9.2. It fixes some issues but does not introduce any new functionality.
Fixed the issue with pdf files not displayed in TeX mode when the path contains spaces.
Fixed a nested calls recursion in TeX::smartSuperscripts.
The following tickets have been closed:
Ticket #234: TeX Synchronization with Skim is broken <https://sourceforge.net/p/alphacocoa/tickets/234/>
Ticket #237: Adapt the size of the selected region when a search-and-replace reduce it <https://sourceforge.net/p/alphacocoa/tickets/237/>
Ticket #239: pageHeader prints untitled instead of document title <https://sourceforge.net/p/alphacocoa/tickets/239/>

Re: [Alphacocoa-devel] [EXT] Alpha Release 9.2 (Gianfar)

From: Panix <da...@pa...> - 2020-10-22 19:08:37

Yay!  Looking forward to it.

David Craig

<http://physics.oregonstate.edu/~craigda>

> On Oct 22, 2020, at 10:20 AM, Bernard Desgraupes <bde...@or...> wrote:
> 
> Hi all,
> 
> I have fixed the issue. The path of the pdf file was not properly url-encoded.
> I will release a minor upgrade tomorrow with the correction.
> 
> Sorry for the inconvenience and thank you again David for spotting the real issue.
> 
> Bernard 
> 
> 
> 
>> Le 22 oct. 2020 à 13:07, Bernard Desgraupes <bde...@or...> a écrit :
>> 
>> Hi David,
>> 
>> thanks for all these experiments. It is very helpful.
>> Finally the problem indeed comes from spaces in the path (Dropbox is declared non guilty !).
>> I see the same problem if I typeset a tex file in a directory with spaces in its name.
>> 
>> I’ll try to fix this as soon as possible.
>> 
>> Cheers,
>> Bernard
>> 
>> 
>>>> Le 22 oct. 2020 à 13:00, David Craig <da...@pa...> a écrit :
>>> 
>>> Hmmm.
>>> 
>>> Well, ALL my files are in DropBox (on my startup disk, which is an SSD).  Dropbox is a central component of my multi-location and multi-machine existence.  I thought that might be it at first, because when I copied a file to my desktop it tex’d and viewed fine in Alpha.  But then I went back to the copy of the identical file in Dropbox, THAT tex’d fine, too.  So some files (just not the first few I tried) preview in Alpha fine, and others don’t.  So I stripped it down to
>>> 
>>> \documentclass{article}
>>> \begin{document}
>>> Document
>>> \end{document}
>>> 
>>> I did a few experiments and have found something pretty suggestive: if the path to the file contains a folder with spaces in the folder name the file won’t display in Alpha.  As soon as I move the /same/ file into a folder with no spaces anywhere in the path, it displays in Alpha.  (My user folder name has no spaces in it, so I don’t know how far up that goes.)
>>> 
>>> David Craig
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> AlphaCocoa-devel mailing list
>> Alp...@li...
>> https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel
>

Re: [Alphacocoa-devel] [EXT] Alpha Release 9.2 (Gianfar)

From: Bernard D. <bde...@or...> - 2020-10-22 17:20:07

Hi all,

I have fixed the issue. The path of the pdf file was not properly url-encoded.
I will release a minor upgrade tomorrow with the correction.

Sorry for the inconvenience and thank you again David for spotting the real issue.

Bernard 



> Le 22 oct. 2020 à 13:07, Bernard Desgraupes <bde...@or...> a écrit :
> 
> Hi David,
> 
> thanks for all these experiments. It is very helpful.
> Finally the problem indeed comes from spaces in the path (Dropbox is declared non guilty !).
> I see the same problem if I typeset a tex file in a directory with spaces in its name.
> 
> I’ll try to fix this as soon as possible.
> 
> Cheers,
> Bernard
> 
> 
>> Le 22 oct. 2020 à 13:00, David Craig <da...@pa...> a écrit :
>> 
>> Hmmm.
>> 
>> Well, ALL my files are in DropBox (on my startup disk, which is an SSD).  Dropbox is a central component of my multi-location and multi-machine existence.  I thought that might be it at first, because when I copied a file to my desktop it tex’d and viewed fine in Alpha.  But then I went back to the copy of the identical file in Dropbox, THAT tex’d fine, too.  So some files (just not the first few I tried) preview in Alpha fine, and others don’t.  So I stripped it down to
>> 
>> \documentclass{article}
>> \begin{document}
>> Document
>> \end{document}
>> 
>> I did a few experiments and have found something pretty suggestive: if the path to the file contains a folder with spaces in the folder name the file won’t display in Alpha.  As soon as I move the /same/ file into a folder with no spaces anywhere in the path, it displays in Alpha.  (My user folder name has no spaces in it, so I don’t know how far up that goes.)
>> 
>> David Craig
>> 
> 
> 
> 
> _______________________________________________
> AlphaCocoa-devel mailing list
> Alp...@li...
> https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel

Re: [Alphacocoa-devel] [EXT] Alpha Release 9.2 (Gianfar)

From: Bernard D. <bde...@or...> - 2020-10-22 11:07:55

Hi David,

thanks for all these experiments. It is very helpful.
Finally the problem indeed comes from spaces in the path (Dropbox is declared non guilty !).
I see the same problem if I typeset a tex file in a directory with spaces in its name.

I’ll try to fix this as soon as possible.

Cheers,
Bernard


> Le 22 oct. 2020 à 13:00, David Craig <da...@pa...> a écrit :
> 
> Hmmm.
> 
> Well, ALL my files are in DropBox (on my startup disk, which is an SSD).  Dropbox is a central component of my multi-location and multi-machine existence.  I thought that might be it at first, because when I copied a file to my desktop it tex’d and viewed fine in Alpha.  But then I went back to the copy of the identical file in Dropbox, THAT tex’d fine, too.  So some files (just not the first few I tried) preview in Alpha fine, and others don’t.  So I stripped it down to
> 
> \documentclass{article}
> \begin{document}
> Document
> \end{document}
> 
> I did a few experiments and have found something pretty suggestive: if the path to the file contains a folder with spaces in the folder name the file won’t display in Alpha.  As soon as I move the /same/ file into a folder with no spaces anywhere in the path, it displays in Alpha.  (My user folder name has no spaces in it, so I don’t know how far up that goes.)
> 
> David Craig
>

Re: [Alphacocoa-devel] [EXT] Alpha Release 9.2 (Gianfar)

From: David C. <da...@pa...> - 2020-10-22 11:00:59

Hmmm.

Well, ALL my files are in DropBox (on my startup disk, which is an SSD).  Dropbox is a central component of my multi-location and multi-machine existence.  I thought that might be it at first, because when I copied a file to my desktop it tex’d and viewed fine in Alpha.  But then I went back to the copy of the identical file in Dropbox, THAT tex’d fine, too.  So some files (just not the first few I tried) preview in Alpha fine, and others don’t.  So I stripped it down to

\documentclass{article}
\begin{document}
Document
\end{document}

I did a few experiments and have found something pretty suggestive: if the path to the file contains a folder with spaces in the folder name the file won’t display in Alpha.  As soon as I move the /same/ file into a folder with no spaces anywhere in the path, it displays in Alpha.  (My user folder name has no spaces in it, so I don’t know how far up that goes.)

David Craig

> On Oct 21, 2020, at 10:55 PM, Bernard Desgraupes <bde...@or...> wrote:
> 
> Hi Chris,
> 
> thanks for the additional information.
> Indeed I see the same problem if I typeset a tex file that is in DropBox : the pdf is blank. Ditto if I try to visualise any pdf from the dropbox in an Alpha pdfviewer. Just tried on High Sierra.
> 
> I have to understand why...
> 
> David, on what kind of volume is your pdf file ?
> 
> Bernard
> 
> 
>> Le 22 oct. 2020 à 07:37, Christopher Skeels <Chr...@un... <mailto:Chr...@un...>> a écrit :
>> 
>> Hi Bernard,
>> 
>> For what it is worth I get a similar outcome to David if I typeset my CV.  It may just be Alpha laughing at me, but that is the only file that has caused me such problems.  It all lives in Dropbox but the pdf that is produced is perfectly readable by Skim, Preview, and Acrobat Reader,  just not Alpha’s in-built viewer.  As I said, other things come up fine, so I hadn’t written sooner because I wasn’t sure what I could tell you.  I attach a screen shot of the window.  Just to reiterate, this is not the norm, just something that my CV does (every time I try).  Otherwise, I have been happily using the new features since the beta was released.
>> 
>> Stay well.
>> 
>> Cheers, Chris.
>> 
>> 
>> -- 
>> 
>> Christopher L. Skeels
>> Secretary, Australasian Standing Committee of the Econometric Society
>> Associate Professor, Department of Economics
>> Director, Econometrics Research Unit
>> Room 327, FBE Building (#105), 111 Barry Street
>> The University of Melbourne
>> VIC 3010 Australia
>>  
>> ORCID: 0000-0003-3632-1933
>> 
>> Tel: (+61) 03 8344 3783 <tel://(+61) 03 8344 3783>
>> Fax: (+61) 03 8344 6899 <tel://(+61) 03 8344 6899>
>> email: Chr...@un... <mailto:Chr...@un...>
>> <Screen Shot 2020-10-22 at 4.34.16 pm.png>
> 

David Craig

<http://www.panix.com/~dac/>

Re: [Alphacocoa-devel] [EXT] Re: Alpha Release 9.2 (Gianfar)

From: Bernard D. <bde...@or...> - 2020-10-22 05:55:41

Hi Chris,

thanks for the additional information.
Indeed I see the same problem if I typeset a tex file that is in DropBox : the pdf is blank. Ditto if I try to visualise any pdf from the dropbox in an Alpha pdfviewer. Just tried on High Sierra.

I have to understand why...

David, on what kind of volume is your pdf file ?

Bernard


> Le 22 oct. 2020 à 07:37, Christopher Skeels <Chr...@un...> a écrit :
> 
> Hi Bernard,
> 
> For what it is worth I get a similar outcome to David if I typeset my CV.  It may just be Alpha laughing at me, but that is the only file that has caused me such problems.  It all lives in Dropbox but the pdf that is produced is perfectly readable by Skim, Preview, and Acrobat Reader,  just not Alpha’s in-built viewer.  As I said, other things come up fine, so I hadn’t written sooner because I wasn’t sure what I could tell you.  I attach a screen shot of the window.  Just to reiterate, this is not the norm, just something that my CV does (every time I try).  Otherwise, I have been happily using the new features since the beta was released.
> 
> Stay well.
> 
> Cheers, Chris.
> 
> 
> -- 
> 
> Christopher L. Skeels
> Secretary, Australasian Standing Committee of the Econometric Society
> Associate Professor, Department of Economics
> Director, Econometrics Research Unit
> Room 327, FBE Building (#105), 111 Barry Street
> The University of Melbourne
> VIC 3010 Australia
>  
> ORCID: 0000-0003-3632-1933
> 
> Tel: (+61) 03 8344 3783 <tel://(+61) 03 8344 3783>
> Fax: (+61) 03 8344 6899 <tel://(+61) 03 8344 6899>
> email: Chr...@un... <mailto:Chr...@un...>
> <Screen Shot 2020-10-22 at 4.34.16 pm.png>