{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":15517578,"defaultBranch":"master","name":"libass","ownerLogin":"astiob","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2013-12-30T00:51:53.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/515193?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1715443817.0","currentOid":""},"activityList":{"items":[{"before":"72c5bc8d39b533cede5d7401c6ff514aff6e28b4","after":"61992a1143bca20f063d083aaf4b692bedbf5a93","ref":"refs/heads/faux-italic-postscript","pushedAt":"2024-05-13T12:04:07.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"Match VSFilter's faux italics on PostScript-outline fonts, too\n\nCoefficient derived experimentally.","shortMessageHtmlLink":"Match VSFilter's faux italics on PostScript-outline fonts, too"}},{"before":"0a63b95ce6dbe6fc3a6470c8b88b242341c8f961","after":"cd223f9dac6a71075f5bfbe59eae8de7cead59f9","ref":"refs/heads/master","pushedAt":"2024-05-13T12:04:07.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"fontselect: overhaul font scoring and faux-ing; fixes #437\n\nThis emulates GDI's behavior, both around scoring and faux decisions.\n\nThe fontconfig provider doesn't provide the full information we'd need to handle this 100% accurately, so it's best-guessed.","shortMessageHtmlLink":"fontselect: overhaul font scoring and faux-ing; <span class=\"issue-keyword tooltipped tooltipped-se\" aria-label=\"This commit closes issue #437.\">fixes</span> <a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"724753775\" data-permission-text=\"Title is private\" data-url=\"https://github.com/libass/libass/issues/437\" data-hovercard-type=\"issue\" data-hovercard-url=\"/libass/libass/issues/437/hovercard\" href=\"https://github.com/libass/libass/issues/437\">libass#437</a>"}},{"before":"18864fa26513cd9758bf975f9416c94811e1c05b","after":"72c5bc8d39b533cede5d7401c6ff514aff6e28b4","ref":"refs/heads/faux-italic-postscript","pushedAt":"2024-05-12T21:53:12.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"Match VSFilter's faux italics on PostScript-outline fonts, too\n\nCoefficient derived experimentally.","shortMessageHtmlLink":"Match VSFilter's faux italics on PostScript-outline fonts, too"}},{"before":"b834142008900241a3082c14dc8a267ebdec49dd","after":"18864fa26513cd9758bf975f9416c94811e1c05b","ref":"refs/heads/faux-italic-postscript","pushedAt":"2024-05-12T21:50:13.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"Match VSFilter's faux italics on PostScript-outline fonts, too\n\nCoefficient derived experimentally.","shortMessageHtmlLink":"Match VSFilter's faux italics on PostScript-outline fonts, too"}},{"before":"2e959274deb92560a9753e9f7765feb7332915ea","after":"b834142008900241a3082c14dc8a267ebdec49dd","ref":"refs/heads/faux-italic-postscript","pushedAt":"2024-05-12T21:21:22.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"Match VSFilter's faux italics on PostScript-outline fonts, too\n\nCoefficient derived experimentally.","shortMessageHtmlLink":"Match VSFilter's faux italics on PostScript-outline fonts, too"}},{"before":"849e0706d7f61e36cf736863c72f607d8ebff6a9","after":null,"ref":"refs/heads/fonts-windows","pushedAt":"2024-05-11T16:10:17.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"}},{"before":"e51781341493e0312f0c7fee66372f0365f7b962","after":"0a63b95ce6dbe6fc3a6470c8b88b242341c8f961","ref":"refs/heads/master","pushedAt":"2024-05-11T16:10:17.000Z","pushType":"push","commitsCount":33,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"checkasm: fix default build on Haiku\n\nHaiku atm builds executeables by defaults as shared libraries\nand with checkasm_fail_func being a global symbol, but assembly\nexpecting to call a local symbol building was broken.\n\nBuilding with -fvisibility=hidden or adding any single one of -pie,\n-no-pie and -Bsymbolic to linking flags also worked around this issue.","shortMessageHtmlLink":"checkasm: fix default build on Haiku"}},{"before":null,"after":"2e959274deb92560a9753e9f7765feb7332915ea","ref":"refs/heads/faux-italic-postscript","pushedAt":"2024-05-11T16:10:17.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"Match VSFilter's faux italics on PostScript-outline fonts, too\n\nCoefficient derived experimentally.","shortMessageHtmlLink":"Match VSFilter's faux italics on PostScript-outline fonts, too"}},{"before":"2385250ddb2f7f16b6474aec89fdaff040228102","after":"3ecd083eafa7889117c3a5dd08788910d9b61413","ref":"refs/heads/debug-fonts","pushedAt":"2024-05-11T16:10:17.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"font: log cmap choice and usage","shortMessageHtmlLink":"font: log cmap choice and usage"}},{"before":null,"after":"bec1ed13f2478b97b391ebe829ca2f32a7252bba","ref":"refs/heads/Remove-unused-include","pushedAt":"2024-05-11T16:10:17.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"[ass_filesystem] Remove unused include\n\nSince ASS_WINAPI_DESKTOP has been centralized, we don't need to include\nass_directwrite.h anymore. We only need to include ass_compat.h","shortMessageHtmlLink":"[ass_filesystem] Remove unused include"}},{"before":"d4e5fc191b93405425451c883f782b938f14ec7a","after":"849e0706d7f61e36cf736863c72f607d8ebff6a9","ref":"refs/heads/fonts-windows","pushedAt":"2024-03-31T00:44:19.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"directwrite: query GDI-enumerated fonts by full name, not family name\n\nFixes: https://github.com/libass/libass/issues/744","shortMessageHtmlLink":"directwrite: query GDI-enumerated fonts by full name, not family name"}},{"before":"378251734aba41d7b26c83ec8654470cf6ae3334","after":"e51781341493e0312f0c7fee66372f0365f7b962","ref":"refs/heads/master","pushedAt":"2024-03-31T00:44:19.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"ci/gha: update checkout action to v4\n\nNode16-based actions are deprecated;\nno adjustments needed for bumping to v4.\n\nThe msys2 actions is already following the latest major release.","shortMessageHtmlLink":"ci/gha: update checkout action to v4"}},{"before":"7ee0f1f744a36a66796a2b237b4526346686ee92","after":null,"ref":"refs/heads/full-unicode-cmap","pushedAt":"2024-02-19T18:49:00.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"}},{"before":"9f21dbe6aeed336632dadd500c98b2ff7eab3cfa","after":"378251734aba41d7b26c83ec8654470cf6ae3334","ref":"refs/heads/master","pushedAt":"2024-02-19T18:49:00.000Z","pushType":"push","commitsCount":6,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"directwrite: fix outdated dealloc code that has become leaky\n\nRegression in commit b6650bd51b4c471c32dd3977ca9416c0b35f6358:\nfullnames and families are no longer allocated, so freeing them\nis pointless, wherease extended_family is allocated in their stead\nand yet is never freed.","shortMessageHtmlLink":"directwrite: fix outdated dealloc code that has become leaky"}},{"before":null,"after":"3887c2113d92277249a69c59ede64f3027461bdf","ref":"refs/heads/directwrite-leak","pushedAt":"2024-02-19T18:49:00.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"directwrite: fix outdated dealloc code that has become leaky\n\nRegression in commit b6650bd51b4c471c32dd3977ca9416c0b35f6358:\nfullnames and families are no longer allocated, so freeing them\nis pointless, wherease extended_family is allocated in their stead\nand yet is never freed.\n\nReported-by: @moi15moi","shortMessageHtmlLink":"directwrite: fix outdated dealloc code that has become leaky"}},{"before":null,"after":"7ee0f1f744a36a66796a2b237b4526346686ee92","ref":"refs/heads/full-unicode-cmap","pushedAt":"2024-01-20T19:21:40.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"font: prefer full-Unicode cmaps to BMP-only ones\n\nFixes: https://github.com/libass/libass/issues/634\nFixes: https://github.com/mpv-player/mpv/issues/13322","shortMessageHtmlLink":"font: prefer full-Unicode cmaps to BMP-only ones"}},{"before":"9f4e6afeec54c0d240a9b8377f27e6c5b7c2bde0","after":"9f21dbe6aeed336632dadd500c98b2ff7eab3cfa","ref":"refs/heads/master","pushedAt":"2024-01-20T19:21:40.000Z","pushType":"push","commitsCount":5,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"drawing: reject drawings not starting with m\n\nFixes https://github.com/libass/libass/issues/719","shortMessageHtmlLink":"drawing: reject drawings not starting with m"}},{"before":"9f4e6afeec54c0d240a9b8377f27e6c5b7c2bde0","after":null,"ref":"refs/heads/style-name","pushedAt":"2023-11-08T21:09:38.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"}},{"before":"e64390522d9501a2c7e6a51c31a5b2a1f3a35cd1","after":"9f4e6afeec54c0d240a9b8377f27e6c5b7c2bde0","ref":"refs/heads/master","pushedAt":"2023-11-08T21:09:38.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"Drop style if strdup(Name) fails rather than try to rename it","shortMessageHtmlLink":"Drop style if strdup(Name) fails rather than try to rename it"}},{"before":"2e0604b5b7d97534a1a5c0ea5bd6cf78588a9403","after":"9f4e6afeec54c0d240a9b8377f27e6c5b7c2bde0","ref":"refs/heads/style-name","pushedAt":"2023-11-08T21:05:56.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"Drop style if strdup(Name) fails rather than try to rename it","shortMessageHtmlLink":"Drop style if strdup(Name) fails rather than try to rename it"}},{"before":"5c15c883a4783641f7e71a6a1f440209965eb64f","after":"e64390522d9501a2c7e6a51c31a5b2a1f3a35cd1","ref":"refs/heads/master","pushedAt":"2023-11-08T21:05:56.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"Adjust spelling of libass in pc file\n\nAll lower case has been the preferred spelling variant\nfor many years now. This is the only place where current\nversions of libass are still referred to as “LibASS”.","shortMessageHtmlLink":"Adjust spelling of libass in pc file"}},{"before":null,"after":"2e0604b5b7d97534a1a5c0ea5bd6cf78588a9403","ref":"refs/heads/style-name","pushedAt":"2023-11-08T20:56:48.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"Drop style if strdup(Name) fails rather than try to rename it","shortMessageHtmlLink":"Drop style if strdup(Name) fails rather than try to rename it"}},{"before":"5c15c883a4783641f7e71a6a1f440209965eb64f","after":null,"ref":"refs/heads/mac-os-x-10.5","pushedAt":"2023-08-22T21:57:00.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"}},{"before":"91422bdb9497e8484b3248f5ae7eb50d41e2555d","after":"5c15c883a4783641f7e71a6a1f440209965eb64f","ref":"refs/heads/master","pushedAt":"2023-08-22T21:57:00.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"Support Core Text on Mac OS X 10.5\n\nBased on the logic in HarfBuzz's hb-coretext. See:\n 1. https://github.com/harfbuzz/harfbuzz/pull/952\n 2. https://github.com/harfbuzz/harfbuzz/pull/1180\n\nCore Text was introduced in 10.5, so this is as far back as we can go.\n\nTested on ppc32 10.5.8 in:\nhttps://github.com/libass/libass/issues/595#issuecomment-1324548120\nManrope Regular failed to be selected by full name,\nbut other fonts (including other faces of Manrope) worked fine,\nso this should be good enough to avoid requiring Fontconfig.\n\nI have tested that the code in the 10.5-compatible branch still works\non 10.13.6 (the newest macOS instance I have access to), but the API\ninvolved is officially \"deprecated\" and produces deprecation warnings\nduring compilation unless the build's deployment target is set to a\nversion below 10.8. In addition, it's not unimaginable that it might\nwork worse in some specific situations now or in the future: for example,\nit uses FSRef, which, according to the docs, is \"designed to work\nwith 32-bit inode numbers\", which \"may result in performance issues\"\non newer systems. As far as I'm aware, Apple doesn't tend to remove\nAPIs/ABIs completely except when combined with architecture changes,\nbut it seems the overall safest course of action is:\n  * to prefer the newer API if it is available at runtime,\n  * and to avoid referencing the older API at all\n    if it's known at compile-time to be unnecessary.\n\nTo nearly maximize build-environment compatibility,\nuse Availability.h and CHECK_AVAILABLE:\n\n  * Recent versions of Apple's compiler support __builtin_available for\n    OS version detection, and so does modern non-Apple Clang. This is what\n    Apple recommends nowadays. However, none of Apple's official compilers\n    on macOS up to 10.10 have had this builtin, and no third-party\n    compilers besides Clang have ever had it. Non-Clang compilers may\n    have issues with Apple's more recent SDK headers anyway, but they're\n    perfectly viable with older SDK releases and all the more likely\n    to be used when the build is being performed on an older machine,\n    e. g. when targeting that same machine, which is precisely where\n    the 10.5-compatible code is most likely to be relevant.\n    On 10.5 or nearby versions, the build is most likely to use one of\n    Apple's old compilers or a custom-built modern upstream GCC.\n\n    Apple's older method of checking for availability at runtime\n    is to check whether the symbol's address is NULL, which works\n    in all of Apple's compilers and in upstream Clang and GCC.\n    We implement this in our CHECK_AVAILABLE macro.\n\n  * There are multiple ways to determine whether the newer symbol\n    is declared at all. To keep it simple, avoid a configure check\n    and stick to a simple macro check.\n\n    In older versions of Apple's SDK, Core Text headers have reacted to\n    \"Mac OS X version max allowed\" control-knob macros and marked newer\n    APIs \"unavailable\" (making any use of them a compilation error) even\n    if they were known to that SDK. However, the exact macros differ\n    between SDK versions, and this mechanism (unlike the \"version min\n    required\") has apparently never been exposed in compiler/IDE knobs\n    and possibly not publicized at all. Newer SDKs also no longer mark\n    symbols unavailable in any case.\n\n    So do the simplest thing and just check for the existence\n    of a macro that was introduced in the same SDK version.\n\n  * In 10.5-10.6 SDKs, Core Text used AvailabilityMacros.h and its\n    MAC_OS_X_VERSION_MIN_REQUIRED; in later versions, it switched to\n    Availability.h and its __MAC_OS_X_VERSION_MIN_REQUIRED with two\n    leading underscores. Both headers are available since 10.5, and\n    Availability.h is more flexible as it has version iOS macros in\n    addition to macOS, which we may need for other APIs in the future,\n    so just use Availability.h.","shortMessageHtmlLink":"Support Core Text on Mac OS X 10.5"}},{"before":"46255cedfb92b1d339d9b8c90537cac82d31e7be","after":"5c15c883a4783641f7e71a6a1f440209965eb64f","ref":"refs/heads/mac-os-x-10.5","pushedAt":"2023-08-21T01:12:38.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"Support Core Text on Mac OS X 10.5\n\nBased on the logic in HarfBuzz's hb-coretext. See:\n 1. https://github.com/harfbuzz/harfbuzz/pull/952\n 2. https://github.com/harfbuzz/harfbuzz/pull/1180\n\nCore Text was introduced in 10.5, so this is as far back as we can go.\n\nTested on ppc32 10.5.8 in:\nhttps://github.com/libass/libass/issues/595#issuecomment-1324548120\nManrope Regular failed to be selected by full name,\nbut other fonts (including other faces of Manrope) worked fine,\nso this should be good enough to avoid requiring Fontconfig.\n\nI have tested that the code in the 10.5-compatible branch still works\non 10.13.6 (the newest macOS instance I have access to), but the API\ninvolved is officially \"deprecated\" and produces deprecation warnings\nduring compilation unless the build's deployment target is set to a\nversion below 10.8. In addition, it's not unimaginable that it might\nwork worse in some specific situations now or in the future: for example,\nit uses FSRef, which, according to the docs, is \"designed to work\nwith 32-bit inode numbers\", which \"may result in performance issues\"\non newer systems. As far as I'm aware, Apple doesn't tend to remove\nAPIs/ABIs completely except when combined with architecture changes,\nbut it seems the overall safest course of action is:\n  * to prefer the newer API if it is available at runtime,\n  * and to avoid referencing the older API at all\n    if it's known at compile-time to be unnecessary.\n\nTo nearly maximize build-environment compatibility,\nuse Availability.h and CHECK_AVAILABLE:\n\n  * Recent versions of Apple's compiler support __builtin_available for\n    OS version detection, and so does modern non-Apple Clang. This is what\n    Apple recommends nowadays. However, none of Apple's official compilers\n    on macOS up to 10.10 have had this builtin, and no third-party\n    compilers besides Clang have ever had it. Non-Clang compilers may\n    have issues with Apple's more recent SDK headers anyway, but they're\n    perfectly viable with older SDK releases and all the more likely\n    to be used when the build is being performed on an older machine,\n    e. g. when targeting that same machine, which is precisely where\n    the 10.5-compatible code is most likely to be relevant.\n    On 10.5 or nearby versions, the build is most likely to use one of\n    Apple's old compilers or a custom-built modern upstream GCC.\n\n    Apple's older method of checking for availability at runtime\n    is to check whether the symbol's address is NULL, which works\n    in all of Apple's compilers and in upstream Clang and GCC.\n    We implement this in our CHECK_AVAILABLE macro.\n\n  * There are multiple ways to determine whether the newer symbol\n    is declared at all. To keep it simple, avoid a configure check\n    and stick to a simple macro check.\n\n    In older versions of Apple's SDK, Core Text headers have reacted to\n    \"Mac OS X version max allowed\" control-knob macros and marked newer\n    APIs \"unavailable\" (making any use of them a compilation error) even\n    if they were known to that SDK. However, the exact macros differ\n    between SDK versions, and this mechanism (unlike the \"version min\n    required\") has apparently never been exposed in compiler/IDE knobs\n    and possibly not publicized at all. Newer SDKs also no longer mark\n    symbols unavailable in any case.\n\n    So do the simplest thing and just check for the existence\n    of a macro that was introduced in the same SDK version.\n\n  * In 10.5-10.6 SDKs, Core Text used AvailabilityMacros.h and its\n    MAC_OS_X_VERSION_MIN_REQUIRED; in later versions, it switched to\n    Availability.h and its __MAC_OS_X_VERSION_MIN_REQUIRED with two\n    leading underscores. Both headers are available since 10.5, and\n    Availability.h is more flexible as it has version iOS macros in\n    addition to macOS, which we may need for other APIs in the future,\n    so just use Availability.h.","shortMessageHtmlLink":"Support Core Text on Mac OS X 10.5"}},{"before":"927565a0365339d8dde2c644a8cb98ff497ff263","after":"46255cedfb92b1d339d9b8c90537cac82d31e7be","ref":"refs/heads/mac-os-x-10.5","pushedAt":"2023-08-06T01:59:24.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"Support Core Text on Mac OS X 10.5\n\nBased on the logic in HarfBuzz's hb-coretext. See:\n 1. https://github.com/harfbuzz/harfbuzz/pull/952\n 2. https://github.com/harfbuzz/harfbuzz/pull/1180\n\nCore Text was introduced in 10.5, so this is as far back as we can go.\n\nTested on ppc32 10.5.8 in:\nhttps://github.com/libass/libass/issues/595#issuecomment-1324548120\nManrope Regular failed to be selected by full name,\nbut other fonts (including other faces of Manrope) worked fine,\nso this should be good enough to avoid requiring Fontconfig.\n\nI have tested that the code in the 10.5-compatible branch still works\non 10.13.6 (the newest macOS instance I have access to), but the API\ninvolved is officially \"deprecated\" and produces deprecation warnings\nduring compilation unless the build's deployment target is set to a\nversion below 10.8. In addition, it's not unimaginable that it might\nwork worse in some specific situations now or in the future: for example,\nit uses FSRef, which, according to the docs, is \"designed to work\nwith 32-bit inode numbers\", which \"may result in performance issues\"\non newer systems. As far as I'm aware, Apple doesn't tend to remove\nAPIs/ABIs completely except when combined with architecture changes,\nbut it seems the overall safest course of action is:\n  * to prefer the newer API if it is available at runtime,\n  * and to avoid referencing the older API at all\n    if it's known at compile-time to be unnecessary.\n\nTo nearly maximize build-environment compatibility,\nuse Availability.h and CHECK_AVAILABLE:\n\n  * Recent versions of Apple's compiler support __builtin_available for\n    OS version detection, and so does modern non-Apple Clang. This is what\n    Apple recommends nowadays. However, none of Apple's official compilers\n    on macOS up to 10.10 have had this builtin, and no third-party\n    compilers besides Clang have ever had it. Non-Clang compilers may\n    have issues with Apple's more recent SDK headers anyway, but they're\n    perfectly viable with older SDK releases and all the more likely\n    to be used when the build is being performed on an older machine,\n    e. g. when targeting that same machine, which is precisely where\n    the 10.5-compatible code is most likely to be relevant.\n    On 10.5 or nearby versions, the build is most likely to use one of\n    Apple's old compilers or a custom-built modern upstream GCC.\n\n    Apple's older method of checking for availability at runtime\n    is to check whether the symbol's address is NULL, which works\n    in all of Apple's compilers and in upstream Clang and GCC.\n    We implement this in our CHECK_AVAILABLE macro.\n\n  * There are multiple ways to determine whether the newer symbol\n    is declared at all. To keep it simple, avoid a configure check\n    and stick to a simple macro check.\n\n    In older versions of Apple's SDK, Core Text headers have reacted to\n    \"Mac OS X version max allowed\" control-knob macros and marked newer\n    APIs \"unavailable\" (making any use of them a compilation error) even\n    if they were known to that SDK. However, the exact macros differ\n    between SDK versions, and this mechanism (unlike the \"version min\n    required\") has apparently never been exposed in compiler/IDE knobs\n    and possibly not publicized at all. Newer SDKs also no longer mark\n    symbols unavailable in any case.\n\n    So do the simplest thing and just check for the existence\n    of a macro that was introduced in the same SDK version.\n\n  * In 10.5-10.6 SDKs, Core Text used AvailabilityMacros.h and its\n    MAC_OS_X_VERSION_MIN_REQUIRED; in later versions, it switched to\n    Availability.h and its __MAC_OS_X_VERSION_MIN_REQUIRED with two\n    leading underscores. Both headers are available since 10.5, and\n    Availability.h is more flexible as it has version iOS macros in\n    addition to macOS, which we may need for other APIs in the future,\n    so just use Availability.h.","shortMessageHtmlLink":"Support Core Text on Mac OS X 10.5"}},{"before":"218dacece7d24b45e4637ced4dc56564de29919d","after":"91422bdb9497e8484b3248f5ae7eb50d41e2555d","ref":"refs/heads/master","pushedAt":"2023-08-06T01:59:24.000Z","pushType":"push","commitsCount":11,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"Plug a memory leak when adding a font on some platforms\n\nOn macOS (with Core Text) and some versions of Windows (with DirectWrite)\n(specifically, Windows 10+ Win32 as well as all versions of WinRT/UWP),\nwe read font metadata on our own via FreeType, filling implicit_meta in\nass_font_provider_add_font. However, we forgot to free it upon successful\nfont registration, leaking the memory allocated for the font name strings.\n\nThe list of affected platforms would likely have expanded in the future,\nas we eventually intend to read font names on our own across the board.\n\nLeak introduced in commit 887e6cc50bfbe8fc354993682edc03c51203e2fc.\n\nAs a quick fix, add the corresponding frees on the successful path.\nIdeally, we should refactor this function to avoid copying any freshly\nallocated memory to begin with (and thus to avoid the need to free it).\n\nFixes: https://github.com/libass/libass/issues/699","shortMessageHtmlLink":"Plug a memory leak when adding a font on some platforms"}},{"before":"77e4bfb977ebd8bcde56f21da88760046a025f39","after":"927565a0365339d8dde2c644a8cb98ff497ff263","ref":"refs/heads/mac-os-x-10.5","pushedAt":"2023-03-12T02:26:37.112Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"Support Core Text on Mac OS X 10.5\n\nBased on the logic in HarfBuzz's hb-coretext. See:\n 1. https://github.com/harfbuzz/harfbuzz/pull/952\n 2. https://github.com/harfbuzz/harfbuzz/pull/1180\n\nCore Text was introduced in 10.5, so this is as far back as we can go.\n\nTested on ppc32 10.5.8 in:\nhttps://github.com/libass/libass/issues/595#issuecomment-1324548120\nManrope Regular failed to be selected by full name,\nbut other fonts (including other faces of Manrope) worked fine,\nso this should be good enough to avoid requiring Fontconfig.\n\nI have tested that the code in the 10.5-compatible branch still works\non 10.13.6 (the newest macOS instance I have access to), but the API\ninvolved is officially \"deprecated\" and produces deprecation warnings\nduring compilation unless the build's deployment target is set to a\nversion below 10.8. In addition, it's not unimaginable that it might\nwork worse in some specific situations now or in the future: for example,\nit uses FSRef, which, according to the docs, is \"designed to work\nwith 32-bit inode numbers\", which \"may result in performance issues\"\non newer systems. As far as I'm aware, Apple doesn't tend to remove\nAPIs/ABIs completely except when combined with architecture changes,\nbut it seems the overall safest course of action is:\n  * to prefer the newer API if it is available at runtime,\n  * and to avoid referencing the older API at all\n    if it's known at compile-time to be unnecessary.\n\nTo maximize build-environment compatibility, use Availability.h,\nincluding __MAC_OS_X_VERSION_MAX_ALLOWED, and a weak-import address check:\n\n  * Recent versions of Apple's compiler support __builtin_available for\n    OS version detection, and so does modern non-Apple Clang. This is what\n    Apple recommends nowadays. However, none of Apple's official compilers\n    on macOS up to 10.10 have had this builtin, and no third-party\n    compilers besides Clang have ever had it. Non-Clang compilers may\n    have issues with Apple's more recent SDK headers anyway, but they're\n    perfectly viable with older SDK releases and all the more likely\n    to be used when the build is being performed on an older machine,\n    e. g. when targeting that same machine, which is precisely where\n    the 10.5-compatible code is most likely to be relevant.\n    On 10.5 or nearby versions, the build is most likely to use one of\n    Apple's old compilers or a custom-built modern upstream GCC.\n\n    Apple's older method of checking for availability at runtime\n    is to check whether the symbol's address is NULL, which works in all\n    of Apple's compilers and in upstream Clang and GCC, so use this.\n\n    This produces a compiler warning in some situations: if the deployment\n    target is 10.6+, the address is always non-NULL, so the condition is\n    trivially true, which warrants a warning. For Clang and for GCC 12+,\n    silence this warning by casting the address to an integer.\n\n    (Note: Clang warns when __builtin_available is unused, but only\n    for symbols introduced in macOS 10.13+, at which point other\n    contemporary or modern compilers can no longer compile\n    ass_coretext due to errors in system headers.)\n\n  * There are multiple ways to determine whether the newer symbol is\n    declared at all. To keep it simple, avoid a configure check and stick\n    to a simple macro check.\n\n    In older versions of Apple's SDK, Core Text headers have reacted to\n    \"Mac OS X version max allowed\" control-knob macros and marked newer\n    APIs \"unavailable\" (making any use of them a compilation error) even\n    if they were known to that SDK. Hence, use one of those same macros\n    (which are still provided and used in newer SDKs although they no\n    longer mark symbols unavailable) as our detection mechanism.\n\n    In 10.5-10.6 SDKs, Core Text used AvailabilityMacros.h and its\n    MAC_OS_X_VERSION_MAX_ALLOWED; in later versions, it switched to\n    Availability.h and its __MAC_OS_X_VERSION_MAX_ALLOWED with two leading\n    underscores. Both headers are available since 10.5, and Availability.h\n    is more flexible as it has version iOS macros in addition to macOS,\n    which we may need for other APIs in the future, so just use\n    Availability.h.","shortMessageHtmlLink":"Support Core Text on Mac OS X 10.5"}},{"before":"57e215f2df98a615119046342ba486f51fd6c0a5","after":"701adc8a122744efc4338170e7ebd0827a019f21","ref":"refs/heads/ci","pushedAt":"2023-03-12T01:54:09.283Z","pushType":"push","commitsCount":1,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"GitHub CI: test on modern macOS a simulated Mac OS X 10.5 build","shortMessageHtmlLink":"GitHub CI: test on modern macOS a simulated Mac OS X 10.5 build"}},{"before":"f196c5079e7bb4f643668a240e4fea3161268076","after":"57e215f2df98a615119046342ba486f51fd6c0a5","ref":"refs/heads/ci","pushedAt":"2023-03-12T01:49:56.653Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"astiob","name":"Oleg Oshmyan","path":"/astiob","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/515193?s=80&v=4"},"commit":{"message":"GitHub CI: build macOS code compatible down to 10.5","shortMessageHtmlLink":"GitHub CI: build macOS code compatible down to 10.5"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"startCursor":"Y3Vyc29yOnYyOpK7MjAyNC0wNS0xM1QxMjowNDowNy4wMDAwMDBazwAAAARIWu2n","endCursor":"Y3Vyc29yOnYyOpK7MjAyMy0wMy0xMlQwMTo0OTo1Ni42NTMzOTdazwAAAAMBeiLU"}},"title":"Activity · astiob/libass"}