#wine-staging

slackner, could you have a look at http://oldwiki.winehq.org/FontReplacements ?

we now provide deb packages / etc to distributions

but we lost the font replacement patch which was previous included by distributions

thanks to jactry, now Wine supports REG_MUL_SZ in font replacement setting, so we might be able to share one configure for all distributions, not sure if that's a good idea

austin987, if http://oldwiki.winehq.org/FontReplacements is included in distributions packages by default, then we don't have to use winetricks

if we can share single configuration why does it have to be patched every time?

nsivov, i'm not sure if julliard likes a hard code configuration in winehq source code

it's not in a source code

it's in registry template

nsivov, we need separate configuration for Mac OS and Linux

on the other hand, it has to be system specific, to handle macs

right

felixonmars suggested to fork kaigen-gothic or other open source fonts ( WenQuanYi Micro Hei, or Source Hans, etc), rename the face name to microsoft CJK font face names, then we can ship those by default in Wine source code

actually i like the idea, but not sure if it is too large to be included in wine source code

maybe a separate package as wine dependency would be better

but, who knows if microsoft will open source some of their fonts in the future? microsoft build 2017? lol

it's unlikely they can do that, most of fonts are licensed from actual font manufacturers

and yes, having dependency on system package is better than a forked font

not to mention possible licensing issues

right, and they have lawsuit with chinese font vendor who invented SimSun...

forked is needed anyway, for font face renaming

it's not necessary needed to be renamed

not a lot depends on that

the idea of font face renaming is for providing same default CJK font on all platform without "font replacement" setting in registry

well, I'd rather use system one, that's regularly updated for me

also, some libraries like JRE directly read the font path from file system and processing font glyph data on their own, for those application "font replacement" setting is not enough because they hardcoded everything

some open Java runtime implementation does that?

yes, maybe we should proposal patch to them?

a patch to rewrite all font processing they have done? why would they want that?

maybe a patch to consider alternative font names and font paths

but this is a good question, i don't have good answer

if we have no good answer, then we have to change Wine to support those broken apps ;)

i don't know what java application is important enough and also windows only, maybe there was but i forgot

I don't consider it broken, windows is guaranteed to always have a set of core fonts, so it's normal to depend on that

do you remember which project does that?

for example, windows version of scilab depends on SimSun font when rendering Chinese

but scilab is open source and has linux version

scilab installer will install jre for users

their jre depends on simsun.tt(?) to be put in C:/windows/Fonts

and the face name should match as well

i think that's the most common jre people used, i didn't found any jre which does not depends on SimSun for Chinese

ok, I'll take a look at scilab then. current version is good for testing?

not sure, didn't test scilab for about one year

downloading scilab-5.5.2.exe, slow here

it was released one year ago, so maybe good for testing

current scilab doesn't run on wine at all

i'm only interested in sources, not going to run it

fracting: just reading the backlog. regarding your patch, i think it should either be upstreamed, or added to wine-staging, but we are not really planning to add distro specific patches

fracting: goal of our builds is to provide both wine and wine-staging as-is, and to avoid "packaging tweaks" which could make it difficult to reproduce bugs

fracting, it's oracle java they provide in prereq pacakage, so not very interesting

nsivov, thanks for looking at it, btw, why oracle java is not very interesting?

nsivov, oh, sorry, missed your previous comment

i did dig into openjdk source code before

i guess they share similar font logic, but i forgot the details now

slackner, different distro has different default cjk fonts, it seems hard to have a single patch for every distros. even we have, we still rely on fallback mechanism, and different distro will still behavior different ;)

fracting: well, ideally it should be solved at runtime. we also cannot really assume that a specific distro will always contain font package X preinstalled

slackner, solved at runtime, maybe by fontconf?

fracting: will have to check whats the best way to do that

slackner, ;)