Hi All,
Since packages SUNWdesktop-cache-root, SUNWdesktop-cache have been
fixed in snv_118,
and they will be integrated to opensolaris from this build. It already
do set extend X
fonts path by locale. This issue should be closed.
But, I tried current 0110.fonts, it can not set any X fonts path,
because, in current
Opensolaris, there is not any locale specific X fonts have been
integrated until Sun-closed
packages net repository have been set up. That means, when Sun-Closed
package net repository
have been set up, we may need repackage our current X fonts of some
locales for Opensolaris.
Of cause these fonts are closed. And then, it maybe need and font
paths to 0110.fonts script.
I will keep on tracking it.
Btw, does anyone when Sun-Closed package net repository will be set up?
Regards,
William
Xue Wei ??:
> Hi Takao,
>
>>>
>>> According to your feedback information, and after I did some
>>> investigation. I think I got solution plan.
>>> For Opensolaris could load locale specific X fonts path. I'd to modify
>>> /etc/X11/xinit/xinitrc.d/0110.fonts scrcipt.
>>> so that X fonts paths could be add by xset when desktop startup except
>>> failsafe terminal login.
>>>
>>> What's current issue? (What need I modified?)
>>> I tested and read 0110.fonts, find that X fonts path could not be
>>> set on
>>> Opensolaris.
>>> It will be set as default. "/usr/X11/bin/xset fp default" would be last
>>> command be run in 0110.fonts.
>>>
>>> The root cause is in Opensolaris there are not X fonts path infor file
>>> OWfontpath.(Add no locale X fonts files either.) such as,
>>> /usr/X11/lib/locale/${Lang}/OWfontpath
>>> or
>>> /usr/openwin/lib/locale/${Lang}/OWfontpath
>>> or
>>> /usr/dt/config/xfonts
>>> or
>>> /etc/dt/config/xfonts
>>> ....
>>>
>>> Solution 1:
>>> Add /usr/X11/lib/locale/${Lang} to Opensolaris, this could be a
>>> symbolic
>>> link from /usr/openwin/lib/locale/${Lang}
>>> This is easy way, but they need IPS package filter convert from Nevada
>>> package.
>>> It is not convenience, and because /usr/openwin/ is a symbolic from
>>> /usr/X11 in Opensolaris, this maybe mess.
>>>
>>> Solution 2:
>>> Create a directory to include X fonts. for example,
>>> /etc/X11/fontpath.d/locale/${Lang}, then add check this directory
>>> action into 0110.fonts.
>>
>> I think it's better to delete /usr/openwin prefix for OpenSolaris if
>> you could.
>
> Thanks for your feedback!
>>
>> Sorry, I mistook one point.
>> If we would configure Sans/Monospace using XLFD likes the old pango,
>> I thought the order of the loading fonts is important.
>> Probably I think you don't need to think the order. I think preparing
>> the symlinks under /etc/X11/fontpath.d and loading all fonts would be
>> no problem unless XLFD encodings are not duplicated.
>> If none UTF-8 could have the problem to load all XLFD, you would need
>> the locale paths.
> I ever though in this way. But, I tough it's not necessary for all
> locale to load so many X fonts, although they are UTF-8 encoding.
> For loading order, yes for XLFD fonts, it does matter for order, they
> named a font by XLFD naming rule.
>
> Regards,
> William
>
>>
>> Thanks,
>> fujiwara
>>
>>>
>>> Which options do you prefer? I'd like to hear your all feedback. Your
>>> feedback/comments will be helpful for me!
>>> Thank you very much!
>>>
>>> Btw, Alan, if I create new directories, it means change the interface.
>>> Do I need a onepager to record it ?
>>>
>>> Thanks!
>>>
>>> Regards,
>>> William
>>>
>>>
>>> Brian Cameron ??:
>>>>
>>>> Xue:
>>>>
>>>>>> This is probably not a problem. The purpose of the failsafe
>>>>>> session is
>>>>>> that it avoids running as much setup as possible. Users typically
>>>>>> use
>>>>>> the failsafe session if they are having troubles logging in
>>>>>> normally,
>>>>>> typically because there is a problem in the session startup. By
>>>>>> avoiding sourcing normal configuration files (such as
>>>>>> $HOME/.profile)
>>>>>> this helps to ensure that any errors in the startup scripts do not
>>>>>> cause the login to fail, allowing the user to try and fix the
>>>>>> problem.
>>>>>> The failsafe session is not intended to be pretty.
>>>>> From your explain, it seems that failsafe do not load more X fonts at
>>>>> all. It's reasonable.
>>>>> So, xinitrc.d/0110.fonts would be a property place to add fonts path,
>>>>> which Takao-san already
>>>>> done. I just need to do some modify. :-)
>>>>
>>>> Sounds reasonable to me. Though it would be handy if you could share
>>>> a proposed patch for review that shows the changes you intend to make.
>>>>
>>>>>> I don't think we should duplicate code. Note that all scripts in the
>>>>>> /etc/X11/xinit/xinitrc.d directory get sourced. They are run in
>>>>>> numeric
>>>>>> order, so a script with the name 0100.foo gets run before
>>>>>> 0110.fonts.
>>>>>> Couldn't you just add a new script to this directory rather than
>>>>>> changing the existing scripts?
>>>>>
>>>>> Oh, sorry, I guess my description is not clear. I do not want to add
>>>>> new script beside 0110.fonts.
>>>>> I mean replace the 0110.fonts script with similar function. But it
>>>>> may be called by different place,
>>>>> eg. called by Xsession or Init/Default.
>>>>
>>>> Yes, that seems reasonable also. Modifying the script so it is more
>>>> generally useful and can be called from other purposes seems a good
>>>> idea.
>>>>
>>>>>>> > Create a evn variable in XFONT_LOCALE to record the specific
>>>>>>> locale.
>>>>>>
>>>>>> What process or script would set this?
>>>>>>
>>>>>>> > Let Init/Default call set_fonts_path script, and set current
>>>>>>> locale to XFONT_LOCALE.
>>>>>>
>>>>>> Why not just edit Init/Default to set XFONT_LOCALE and run the
>>>>>> 0110.fonts script rather than duplicating code?
>>>>>>
>>>>>>> > In xinit/xinitrc.d/0110.fonts, Check XFONT_LOCALE, if it is NULL,
>>>>>>> or not same with current
>>>>>>> locale value, cleanup current locale specific X fonts path. and
>>>>>>> re-set it according to current locale.
>>>>>>
>>>>>> Couldn't you create a new script 0105.locale to cleanup locale
>>>>>> specific
>>>>>> X fonts path and reset it to current locale?
>>>>> Could this function be done at Xsession?
>>>>
>>>> There are probably many different ways we could solve this problem.
>>>> The /etc/X11/gdm/Xsession script already sources the files in
>>>> /etc/X11/xinit/xinitrc.d. So, you could probably fix this by making
>>>> changes in the Xsession script directly.
>>>>
>>>> However, note that this Xsession script is really a part of the GDM
>>>> module, while the files in /etc/X11/xinit/xinitrc.d are in a package
>>>> owned by Sun which contains Sun-specific modifications to how the
>>>> session startup should work.
>>>>
>>>> Therefore, the /etc/X11/xinit/xinitrc.d scripts are a better place to
>>>> put Sun-specific configuration. Putting distro-specific code in the
>>>> GDM Xsession script is not ideal since we then have to maintain a Sun
>>>> specific patch to make the change. Such changes are hard to get
>>>> upstream. So, if it is possible to address this issue in the
>>>> /etc/X11/xinit/xinitrc.d scripts, that is a better solution for making
>>>> distro-specific configuration.
>>>>
>>>> Note that the scripts in the /etc/X11/xinit/xinitrc.d directory are
>>>> sourced in numeric order, so a script which starts with 0105 in the
>>>> filename is run before a script which starts with 0110 in the
>>>> filename, and so on.
>>>>
>>>> Does this make sense?
>>>>
>>>> Brian
>>>
>>>
>>
>
