<html><head></head><body><div style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><div>Hi,<br><br>First of all, Tom, it's definitely a good thing you've done, and I agree that using _wfopen() on Windows is the way to go. Personally I can live with this either way. It's controllable so I can deal with it, no worries.<br><br>That said, I believe this is an API break. Functions that used to only accept codepage strings now only accept UTF-8 strings. An analogy would be a function which used to take a signed integer and now starts interpreting it as an unsigned integer. Or one which used to take integers and now switched to floats. And in my opinion, adding heuristics for determining the format of the input would just open up to new problems down the line. If you have data that you don't know the format of and you pass that to a library like Cairo then you're doing it wrong. Fix your data.<br><br>So if it were my code I would add new API and deprecate the old, but it's certainly not the end of the world :)<br><br>All the best,<br><br>Mikael</div>
            <div><br></div><div><br></div>
            
            <div id="yahoo_quoted_5678400395" class="yahoo_quoted">
                <div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
                    
                    <div>
                        On Friday, January 5, 2018, 10:24:11 AM GMT+1,  <tom.schoonjans@diamond.ac.uk> wrote:
                    </div>
                    <div><br></div>
                    <div><br></div>
                    <div><div dir="ltr">Hi all,<br clear="none"><br clear="none"><br clear="none">I am the author of the commit that added UTF-8 support for Windows.<br clear="none"><br clear="none">First I would like to state that I was indeed wrong to say that it enforces UTF-8 encoded filenames on all platforms. What I should have said is:<br clear="none"><br clear="none">On Windows filenames are assumed to be encoded in UTF-8, while on other platforms the current filename encoding will be used (which is usually UTF-8).<br clear="none"><br clear="none">In my experience, this is the most commonly observed behavior in the majority of open source projects out there, especially those in the GNOME ecosystem (Glib, Gtk+, libxml…).<br clear="none"><br clear="none">I would also argue that this is not an API breakage, but it does require the user to take into account this new behavior when running his/her software on Windows.<br clear="none"><br clear="none">Mikael, your usage of g_win32_locale_filename_from_utf8 is actually a bit dangerous since it will still fail in some (admittedly exotic) cases. The implementation of this function (<a shape="rect" href="https://github.com/GNOME/glib/blob/75fa8c2afbab4f414d2eb03684d9f807bd690aef/glib/gwin32.c#L692" target="_blank">https://github.com/GNOME/glib/blob/75fa8c2afbab4f414d2eb03684d9f807bd690aef/glib/gwin32.c#L692</a>) reveals that it will first try to convert the UTF-8 filename to the current codepage encoding, which will fail if not all characters can be represented in this codepage. In this case it will fall back to using the short filename (8.3) using GetShortPathNameW, which is not supported by all filesystems. My patch does not suffer from these issues as it uses the wide char Unicode API behind the scenes to open the files. I would also like to remark that Microsoft is actively discouraging the use of codepages because of their known problems and limitations, which is one of the reasons why I thought my patch would be a good idea… In your case Mikael, if you need to support versions of cairo that are older than 1.15.10, you will indeed need to do a cairo runtime version check to determine whether you need to call g_win32_locale_filename_from_utf8 or not.<br clear="none"><br clear="none">In summary, please do not revert this patch. It introduces proper handling of filenames in a manner that is similar to many other popular packages, and is guaranteed to work on all platforms, something that couldn’t be achieved until now on Windows.<br clear="none"><br clear="none"><br clear="none">Best regards,<br clear="none"><br clear="none">Tom<br clear="none"><br clear="none">Dr Tom Schoonjans<br clear="none">Data Analysis Scientist<br clear="none">Tel: +44 1235 56 7507<br clear="none"><br clear="none">Diamond Light Source Ltd.<br clear="none">Diamond House<br clear="none">Harwell Science & Innovation Campus<br clear="none">Didcot<br clear="none">Oxfordshire<br clear="none">OX11 0DE<br clear="none">United Kingdom<br clear="none"><br clear="none">On 5 Jan 2018, at 00:56, Bryce Harrington <<a shape="rect" ymailto="mailto:bryce@osg.samsung.com" href="mailto:bryce@osg.samsung.com">bryce@osg.samsung.com</a><mailto:<a shape="rect" ymailto="mailto:bryce@osg.samsung.com" href="mailto:bryce@osg.samsung.com">bryce@osg.samsung.com</a>>> wrote:<br clear="none"><br clear="none">[Adding to CC]<br clear="none"><br clear="none">I'd like to see further discussion on Mikael's proposal.<br clear="none"><br clear="none">Does the change to the handling of the filename content actually qualify<br clear="none">as an API break?  The previous implementation was underspecified as to<br clear="none">the filename's format, although it would seem reasonable to assume it's<br clear="none">an ordinary C string, so this does appear to at least qualify as a<br clear="none">behavior change.<br clear="none"><br clear="none">Having the routine specified one way on Windows, and a different way on<br clear="none">non-Windows seems a bit odd to me, and maybe it does raise a red flag<br clear="none">that we're really dealing with separate functions conceptually.  Unless,<br clear="none">would there be any way for this to auto-detect the string format of the<br clear="none">filename, and if it is not UTF-8 to fall back to the original behavior?<br clear="none"><br clear="none">I'll hold off reverting the patch for a week or so in hopes the<br clear="none">discussion to come up with a good plan, and maybe patches.<br clear="none"><br clear="none">Bryce<br clear="none"><br clear="none"><br clear="none">On Wed, Dec 27, 2017 at 02:06:07PM +0000, Mikael Claesson wrote:<br clear="none">Hi Uli,<br clear="none">It aborts and shows an error dialog - not ideal. Internally, I keep file names in UTF-8 so really I like the idea of passing UTF-8 filenames to cairo, but I'm concerned that we now have different incompatible behaviour in different versions of cairo.<br clear="none">Before passing a file name to cairo I run it through g_win32_locale_filename_from_utf8(). And on Linux I use g_filename_from_utf8().<br clear="none">I noticed that the git commit has this comment: "This patch enforces the use of UTF-8 filenames on all platforms." That doesn't seem correct to me. While UTF-8 is by far the most common filename encoding on Linux, I don't think this is always the case, and that is why we have g_filename_from_utf8(). I may be completely wrong - I only started trying to wrap my head around this stuff recently - but I think calling fopen() with a UTF-8 string without first making sure which encoding is correct for the system is a bug?<br clear="none">If I'm correct, then I suggest reverting the change and instead adding new API functions in parallell with the existing ones, that do take UTF-8 encoded filenames on all platforms. I would definitely use them.<br clear="none">Best regards,<br clear="none">Mikael<br clear="none">   On Wednesday, December 27, 2017, 9:24:19 AM GMT+1, Uli Schlachter <<a shape="rect" ymailto="mailto:psychon@znc.in" href="mailto:psychon@znc.in">psychon@znc.in</a><mailto:<a shape="rect" ymailto="mailto:psychon@znc.in" href="mailto:psychon@znc.in">psychon@znc.in</a>>> wrote:<br clear="none"><br clear="none">Hi,<br clear="none"><br clear="none">I can't answer your question, but I have a question to you: What does<br clear="none">your application do if the file name cannot be expressed in the current<br clear="none">codepage?<br clear="none"><br clear="none">Cheers,<br clear="none">Uli<br clear="none"><br clear="none">On 26.12.2017 22:10, Mikael Claesson wrote:<br clear="none">Hi,<br clear="none">What is the recommended way of dealing with the "Use UTF-8 filenames on Windows" change? Will that not break API/ABI? In my application I currently have code in place to ensure that the file names are encoded in the current codepage. I guess I will now have to first check which cairo version the user has, and then convert as needed? Are all applications expected to do this?<br clear="none">Best regards,<br clear="none">Mikael<br clear="none"><br clear="none"><br clear="none">    On Tuesday, December 12, 2017, 2:06:42 AM GMT+1, Bryce Harrington <<a shape="rect" ymailto="mailto:bryce@osg.samsung.com" href="mailto:bryce@osg.samsung.com">bryce@osg.samsung.com</a><mailto:<a shape="rect" ymailto="mailto:bryce@osg.samsung.com" href="mailto:bryce@osg.samsung.com">bryce@osg.samsung.com</a>>> wrote:<br clear="none"><br clear="none">  A new cairo snapshot 1.15.10 is now available from:<br clear="none"><br clear="none">  <a shape="rect" href="http://cairographics.org/snapshots/cairo-1.15.10.tar.xz" target="_blank">http://cairographics.org/snapshots/cairo-1.15.10.tar.xz</a><br clear="none"><br clear="none">    which can be verified with:<br clear="none"><br clear="none">    <a shape="rect" href="http://cairographics.org/snapshots/cairo-1.15.10.tar.xz.sha1" target="_blank">http://cairographics.org/snapshots/cairo-1.15.10.tar.xz.sha1</a><br clear="none">    de180498ac563249b93ee5e17ba9aa26f90644b3  cairo-1.15.10.tar.xz<br clear="none"><br clear="none">    <a shape="rect" href="http://cairographics.org/snapshots/cairo-1.15.10.tar.xz.sha1.asc" target="_blank">http://cairographics.org/snapshots/cairo-1.15.10.tar.xz.sha1.asc</a><br clear="none">    (signed by Bryce Harrington)<br clear="none"><br clear="none">  Additionally, a git clone of the source tree:<br clear="none"><br clear="none">  git clone git://git.cairographics.org/git/cairo<br clear="none"><br clear="none">    will include a signed 1.15.10 tag which points to a commit named:<br clear="none">    95c464d5feaae58b6cc0990434ce2498cc315dc6<br clear="none"><br clear="none">    which can be verified with:<br clear="none">    git verify-tag 1.15.10<br clear="none"><br clear="none">    and can be checked out with a command such as:<br clear="none">    git checkout -b build 1.15.10<br clear="none"><br clear="none"><br clear="none">Release 1.15.10    (2017-12-07 Bryce Harrington <<a shape="rect" ymailto="mailto:bryce@osg.samsung.com" href="mailto:bryce@osg.samsung.com">bryce@osg.samsung.com</a><mailto:<a shape="rect" ymailto="mailto:bryce@osg.samsung.com" href="mailto:bryce@osg.samsung.com">bryce@osg.samsung.com</a>>>)<br clear="none">========================================================================<br clear="none">This release adds GLESv3 support to the cairo_gl backend, adds<br clear="none">tracking of SVG units in generated svg documents, and cleans up numerous<br clear="none">test failures and related issues in the PDF and Postscript backends.<br clear="none"><br clear="none">For a complete log of changes, please see<br clear="none"><br clear="none">    <a shape="rect" href="http://cairographics.org/releases/ChangeLog.1.15.10" target="_blank">http://cairographics.org/releases/ChangeLog.1.15.10</a><br clear="none"><br clear="none">Features and Enhancements<br clear="none">-------------------------<br clear="none">* Add support for OpenGL ES 3.0 to the gl backend.<br clear="none">* Use Reusable streams for forms in Level 3 Postscript.<br clear="none">* Add CAIRO_MIME_TYPE_EPS mime type for embedding EPS files.<br clear="none">* Add CCITT_FAX mime type for PDF and PS surfaces<br clear="none">* svg: add a new function to specify the SVG document unit<br clear="none">  (Bug #90166)<br clear="none">* Use UTF-8 filenames on Windows<br clear="none"><br clear="none">API Changes<br clear="none">-----------<br clear="none">* cairo_svg_surface_set_document_unit() and<br clear="none">  cairo_svg_surface_get_document_unit()<br clear="none"><br clear="none">Dependency Changes<br clear="none">------------------<br clear="none">None<br clear="none"><br clear="none">Performance Optimizations<br clear="none">-------------------------<br clear="none">None<br clear="none"><br clear="none">Bug Fixes<br clear="none">---------<br clear="none">* Fix regression in gles version detection<br clear="none">* Fix undefined-behavior with integer math.<br clear="none">* Handle SOURCE and CLEAR operators when painting color glyphs.<br clear="none">  (Bug #102661)<br clear="none">* Convert images to rgba or a8 formats when uploading with GLESv2<br clear="none">* Use _WIN32 instead of windows.h to check for windows build.<br clear="none">* Fix sigabrt printing documents with fonts lacking the mandatory .nodef<br clear="none">  glyph.<br clear="none">  (Bug #102922)<br clear="none">* Prevent curved strokes in small ctms from being culled from vector<br clear="none">  surfaces<br clear="none">  (Bug #103071)<br clear="none">* Fix painting an unbounded recording surface with the SVG backend.<br clear="none">* Fix falling back to system font with PDFs using certain embedded<br clear="none">  fonts, due to truncated font names.<br clear="none">  (Bug #103249)<br clear="none">* Fix handling of truetype fonts with excessively long font names<br clear="none">  (Bug #103249)<br clear="none">* Fix race conditions with cairo_mask_compositor_t<br clear="none">  (Bug #103037)<br clear="none">* Fix build error with util/font-view<br clear="none">* Fix assertion hit with PDFs using Type 4 fonts rendered with user<br clear="none">  fonts, due to error when destroying glyph page.<br clear="none">  (Bug #103335)<br clear="none">* Set default creation date for PDFs<br clear="none">* Prevent invalid ptr access for > 4GB images.<br clear="none">  (Bug #98165)<br clear="none">* Prevent self-copy infinite loop in Postscript surface.<br clear="none">* Fix padded image crash in Postscript surface.<br clear="none">* Fix annotation bugs in PDFs and related memory leaks<br clear="none">* Fix test failures and other assorted issues in ps and pdf code.<br clear="none">* Fix code generation when using GCC legacy atomic operations<br clear="none">  (Bug #103559)<br clear="none">* Fix various compilation warnings and errors.<br clear="none">* Fix various distcheck errors with private symbols, doxygen formatting,<br clear="none">  etc.<br clear="none"><br clear="none">See below for a complete log of changes since 1.15.8, or see:<br clear="none"><br clear="none">    <a shape="rect" href="http://cairographics.org/releases/ChangeLog.cairo-1.15.10" target="_blank">http://cairographics.org/releases/ChangeLog.cairo-1.15.10</a><br clear="none"><br clear="none"><br clear="none"><br clear="none">What is cairo<br clear="none">-------------<br clear="none">Cairo is a 2D graphics library with support for multiple output<br clear="none">devices. Currently supported output targets include the X Window<br clear="none">System (via both Xlib and XCB), quartz, win32, and image buffers,<br clear="none">as well as PDF, PostScript, and SVG file output. Experimental backends<br clear="none">include OpenGL, BeOS, OS/2, and DirectFB.<br clear="none"><br clear="none">Cairo is free software and is available to be redistributed and/or<br clear="none">modified under the terms of either the GNU Lesser General Public<br clear="none">License (LGPL) version 2.1 or the Mozilla Public License (MPL) version<br clear="none">1.1.<br clear="none"><br clear="none"><br clear="none">Where to get more information about cairo<br clear="none">-----------------------------------------<br clear="none">The primary source of information about cairo is:<br clear="none"><br clear="none">        <a shape="rect" href="http://cairographics.org/" target="_blank">http://cairographics.org/</a><br clear="none"><br clear="none">The latest versions of cairo can always be found at:<br clear="none"><br clear="none">        <a shape="rect" href="http://cairographics.org/download" target="_blank">http://cairographics.org/download</a><br clear="none"><br clear="none">Documentation on using cairo and frequently-asked questions:<br clear="none"><br clear="none">        <a shape="rect" href="http://cairographics.org/documentation" target="_blank">http://cairographics.org/documentation</a><br clear="none">        <a shape="rect" href="http://cairographics.org/FAQ" target="_blank">http://cairographics.org/FAQ</a><br clear="none"><br clear="none"><br clear="none">Mailing lists for contacting cairo users and developers:<br clear="none"><br clear="none">        <a shape="rect" href="http://cairographics.org/lists" target="_blank">http://cairographics.org/lists</a><br clear="none"><br clear="none">Roadmap and unscheduled things to do, (please feel free to help out):<br clear="none"><br clear="none">        <a shape="rect" href="http://cairographics.org/roadmap" target="_blank">http://cairographics.org/roadmap</a><br clear="none">        <a shape="rect" href="http://cairographics.org/todo" target="_blank">http://cairographics.org/todo</a><br clear="none"><br clear="none"><br clear="none"><br clear="none">Changes since 1.15.8<br clear="none">--------------------<br clear="none"><br clear="none">Adrian Johnson (47):<br clear="none">      RELEASING: use correct branch name<br clear="none">      Remove unused variable<br clear="none">      build: use _WIN32 instead of windows.h to check for windows build<br clear="none">      replace _BSD_SOURCE with _DEFAULT_SOURCE<br clear="none">      factor out ascii to double code in cff-subset into _cairo_strtod<br clear="none">      truetype: reserve space in subset arrays for .notdef<br clear="none">      truetype: clarify glyph count variables<br clear="none">      Prevent curved strokes in small ctms from being culled from vector surfaces<br clear="none">      svg: fix painting an unbounded recording surface<br clear="none">      output-stream: allow %s strings larger than 512 chars<br clear="none">      truetype: limit font name to 127 chars<br clear="none">      svg: use hash table instead of user_data to track emitted surfaces<br clear="none">      svg: source surface hash table does not need to hold the source<br clear="none">      svg2png: remove unused headers<br clear="none">      ft: prevent unused var warning when freetype < 2.8<br clear="none">      fix unused function warnings<br clear="none">      svg: recording_surface is needed even if not emitted<br clear="none">      fix warning: variable X might be clobbered by 'longjmp'<br clear="none">      fix warning: inlining failed in call to '_csi_stack_push'<br clear="none">      util/font-view: fix build error<br clear="none">      Add CCITT_FAX mime type for PDF and PS surfaces<br clear="none">      Allow mime image to be different size to cairo image<br clear="none">      pdf: set ca/CA instead of using an smask when the mask has constant alpha<br clear="none">      pdf: set default create date<br clear="none">      pdf: remove old comment<br clear="none">      image: prevent invalid ptr access for > 4GB images<br clear="none">      Add mime-unique-id test<br clear="none">      pdf: fix mime-unique-id bounded recording test<br clear="none">      pdf: fix mime-unique-id unbounded recording test<br clear="none">      pdf: fix mime-unique-id jpeg attached to recording test<br clear="none">      ps: emit base85 strings instead of strings of base85<br clear="none">      ps: remove unused prolog<br clear="none">      ps: use << >> for dictionaries instead of dict begin end<br clear="none">      ps: don't acquire image or snapshot in acquire_source_image_from_pattern<br clear="none">      ps: use forms for surfaces with UNIQUE_ID mime type<br clear="none">      ps: use Reusable streams for forms in Level 3<br clear="none">      ps: add CAIRO_MIME_TYPE_EPS mime type for embedding EPS files<br clear="none">      test: use CAIRO_MIME_TYPE_UNIQUE_ID with record-text-transform<br clear="none">      ps: prevent self-copy infinite loop<br clear="none">      ps: fix padded image crash<br clear="none">      ps: fix extend-*-similar failures<br clear="none">      test: update some stale ref images<br clear="none">      pdf: fix document structure for non tagged structures<br clear="none">      ps: fix compile with old versions of MSVC<br clear="none">      pdf: fix some annotation bugs<br clear="none">      Prevent -Wundef warnings in when cairo-ft.h is used without fontconfig<br clear="none">      ps: fix compile warning<br clear="none"><br clear="none">Aleksander Morgado (1):<br clear="none">      build: fix minor typo in autogen.sh<br clear="none"><br clear="none">Antonio Ospite (2):<br clear="none">      svg: add a new function to specify the SVG document unit<br clear="none">      svg: fix compilation with MSVC which doesn't support C99 initializers<br clear="none"><br clear="none">Behdad Esfahbod (2):<br clear="none">      Fix undefined-behavior with integer math<br clear="none">      Handle SOURCE and CLEAR operators when painting color glyphs<br clear="none"><br clear="none">Bryce Harrington (15):<br clear="none">      Bump version for new development tree, 1.15.9<br clear="none">      glesv2: Fix regression in gles version detection<br clear="none">      gl: Convert images to rgba or a8 formats when uploading with GLESv2<br clear="none">      gl: Make _cairo_gl_ensure_framebuffer a private shared routine<br clear="none">      gl: Add support for OpenGL ES 3.0<br clear="none">      Factor out the ISFINITE() macro<br clear="none">      configure: Check for typeof<br clear="none">      Un-doxygen disabled cairo_set_opacity<br clear="none">      image: Fix include for use of ptrdiff<br clear="none">      win32: Fix since field version number<br clear="none">      Fix various doxygen warnings found by check-doc-syntax.sh<br clear="none">      Fix distcheck errors on use of #ifdef<br clear="none">      pattern: Mark a private routine as cairo_private.<br clear="none">      1.15.10 release<br clear="none">      Bump version for new development tree, 1.15.9<br clear="none"><br clear="none">Carlos Garcia Campos (1):<br clear="none">      scaled-font: Fix assert when destroying glyph page<br clear="none"><br clear="none">Mikhail Fludkov (2):<br clear="none">      Surround initialisations with atomic critical section<br clear="none">      Fix code generation when using GCC legacy atomic operations<br clear="none"><br clear="none">Tom Schoonjans (1):<br clear="none">      Use UTF-8 filenames on Windows<br clear="none"><br clear="none"><br clear="none"><br clear="none"><br clear="none"><br clear="none">--<br clear="none">"In the beginning the Universe was created. This has made a lot of<br clear="none">people very angry and has been widely regarded as a bad move."<br clear="none"><br clear="none"><br clear="none">--<br clear="none">cairo mailing list<br clear="none"><a shape="rect" ymailto="mailto:cairo@cairographics.org" href="mailto:cairo@cairographics.org">cairo@cairographics.org</a><mailto:<a shape="rect" ymailto="mailto:cairo@cairographics.org" href="mailto:cairo@cairographics.org">cairo@cairographics.org</a>><div class="yqt8691524800" id="yqtfd30462"><br clear="none"><a shape="rect" href="https://lists.cairographics.org/mailman/listinfo/cairo" target="_blank">https://lists.cairographics.org/mailman/listinfo/cairo</a></div><br clear="none"><br clear="none"><br clear="none"><br clear="none">-- <br clear="none">This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.<br clear="none">Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. <br clear="none">Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.<br clear="none">Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom<div class="yqt8691524800" id="yqtfd86484"><br clear="none"></div></div></div>
                </div>
            </div></div></body></html>