it’s time to boogie down

  • 2 Posts
  • 16 Comments
Joined 3 years ago
Cake day: June 21st, 2023
  • hitagi@ani.socialtoFediverse@lemmy.world•An honest discussion in the current state of the FediverseEnglish
    2·
    4 months ago

    I don’t think the Fediverse will surpass mainstream social media by any means. I genuinely don’t believe there will be a day where any Fediverse platform will reach even a tenth of the userbase of its mainstream counterpart.

    The current trend of Fediverse platforms seems to operate in this way: “make X ActivityPub compatible” where X is any existing or emerging mainstream platform. A good example is Loops which, I feel is completely disconnected from the TikTok userbase that it attempts to capture. TikTok is very popular precisely because of its addictive algorithm and I’m not sure if the ethics of Loops will follow in that direction.

    Although the Fediverse population is small, I think it’s pretty resilient at least. We’re all here because of a shared ideal of “social media” that isn’t owned by a single entity. Unless users outside the Fediverse share the same ideal, it is unlikely they’ll stick around.

    The three problems listed on your post have pretty much been the same for the past three years and I don’t think anyone has made a good solution for it (otherwise, it would have blown up by now). There are so many suggestions like making a quiz or choosing a random instance but we all know those come with their own flaws. I don’t know how many years it will take for us to solve this problem but I’m always happy to see new attempts at solving them. The funny thing though is that some of these solutions rely on centralization…

    However, in my opinion, I think we are approaching the Fediverse wrong. The current expectation is it to eventually replace mainstream social media (it won’t). There is an obsession with a grand narrative or even a utopia.

    In my opinion, the “new” problem of the Fediverse should be this:

    “How do you build a platform with decentralization first in mind?”

    If we start thinking about this question, then problems like “choosing a server” should be irrelevant. I think about this question almost every day and I’m always on the look out for new platforms (both Fediverse and non-Fediverse) that hopefully aren’t just “X but ActivityPub”. I hope there will be more effort put into developing a platform where choosing an instance isn’t thought to be a hindrance but is actually part of the experience. A platform where we aren’t actively trying to “hide” decentralization.

    The question might sound stupid for some but just try to think about how we’re always chasing after mainstream social media and never really coming up with something original and unique where features are designed around decentralized interactions first.

    I don’t have the answers to this problem but I hope we can change the way we think about the Fediverse.

  • hitagi@ani.socialOPtoLinux@lemmy.world•How do I fix inconsistent CJK font weights in Fedora KDE?English
    1·
    8 months ago

    UPDATE: In case anyone comes across this thread…

    Fedora KDE really doesn’t seem to render Noto Sans CJK JP and KR very well. GNOME and GTK apps can render it fine. I couldn’t find a proper fix for it but either one of these workarounds should be good enough:

    1. Set your main font as Noto Sans CJK “Light” --> this looks okay for KDE/Qt but GTK apps will properly render it as “Light”
    2. Use a different font and use fontconfig to prefer those fonts

    Number 2 is a better solution. https://fonts.google.com/ has a bunch of fonts for most languages and many of them have packages in Fedora. In my case, I installed mrsw-biz-* and naver-nanum-* and added this to my fontconfig (~/.config/fontconfig/conf.d/00-preferred-fonts.conf:

    <?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "urn:fontconfig:fonts.dtd">
<fontconfig>

  <alias>
    <family>sans-serif</family>
    <prefer>
      <family>Noto Sans</family>
      <family>BIZ UDPGothic</family>
      <family>NanumGothic</family>
    </prefer>
  </alias>

  <alias>
    <family>monospace</family>
    <prefer>
      <family>Noto Sans Mono</family>
      <family>BIZ UDGothic</family>
      <family>NanumGothicCoding</family>
    </prefer>
  </alias>

</fontconfig>
  • hitagi@ani.socialOPtoLinux@lemmy.world•How do I fix inconsistent CJK font weights in Fedora KDE?English
    1·
    8 months ago

    For all/relevant encodings?

    As far as I understand (Firefox Font settings, using fc-match, fontconfig, etc), it’s properly configured.

    Have you considered that maybe Noto developers made a choice there, to render Kanjoi thicker than Chinese characters?

    Assuming you meant Kana (and Hangeul as well), I’m not sure why they would do that because it makes it appear so inconsistent.

    I know, that doesn’t explain why Dolphin would render them in a way that is more pleasing to you. Have you tried using other fonts altogether?

    You mean Firefox (and the Firefox file picker) because Dolphin doesn’t render it well at all. I actually tested a few things. I uninstalled the Noto Sans CJK package to see what other fonts it would fall back to. It falls back to Droid Sans and it looks pretty good in my opinion. It doesn’t become thick like Noto Sans CJK. So maybe it’s really something intentionally done by the Noto developers.

    BUT Noto Sans CJK looks fine in Firefox, LibreOffice, and GIMP.

    A few more things I tested:

    1. Bazzite live ISO on a virtual machine also has thick Kana and Hangeul (problem isn’t limited to Fedora KDE?)
    2. Flatpak Strawberry and Dolphin results in Chinese/Kanji becoming thick (???)
    3. Fedora GNOME renders CJK fine (KDE issue?)
    4. Nautilus on Fedora KDE renders CJK fine (Qt issue?)
    5. Changed the fallback font for ja and ko via ~/.config/fontconfig/fonts.conf to Droid Sans Fallback (I also tried setting it to Noto Sans CJK Light), then confirming changes using fc-match. Restarted and cleared fc-cache. Dolphin and Strawberry did not respect my changes. Nautilus does though. (Qt issue?)
    6. Replaced CJK VF fonts with non-VF fonts. No difference.

    Something tells me it’s a KDE or Qt thing, or maybe it’s a Fedora thing? It works fine with GNOME and GTK apps like Nautilus. This is beyond what I know at this point so I’ll just post this over to the Fedora forums.

  • hitagi@ani.socialOPtoLinux@lemmy.world•How do I fix inconsistent CJK font weights in Fedora KDE?English
    1·
    8 months ago
    $ fc-match "default font"
NotoSans-Regular.ttf: "Noto Sans" "Regular"

    This seems to be correct.

    $ fc-match :lang=ja
NotoSansCJK-Regular.ttc: "Noto Sans CJK JP" "Regular"

    Also seems to be correct.

    I skimmed through the primer and checked whats on the default fontconfig config:

    $ cat ~/.config/fontconfig/fonts.conf 
<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'urn:fontconfig:fonts.dtd'>
<fontconfig>
 <!-- 
 Artificial oblique for fonts without an italic or oblique version
 -->
 <match target="font">
  <!-- check to see if the font is roman -->
  <test name="slant">
   <const>roman</const>
  </test>
  <!-- check to see if the pattern requested non-roman -->
  <test compare="not_eq" name="slant" target="pattern">
   <const>roman</const>
  </test>
  <!-- multiply the matrix to slant the font -->
  <edit mode="assign" name="matrix">
   <times>
    <name>matrix</name>
    <matrix>
     <double>1</double>
     <double>0.2</double>
     <double>0</double>
     <double>1</double>
    </matrix>
   </times>
  </edit>
  <!-- pretend the font is oblique now -->
  <edit mode="assign" name="slant">
   <const>oblique</const>
  </edit>
  <!-- and disable embedded bitmaps for artificial oblique -->
  <edit mode="assign" name="embeddedbitmap">
   <bool>false</bool>
  </edit>
 </match>
 <!--
 Synthetic emboldening for fonts that do not have bold face available
 -->
 <match target="font">
  <!-- check to see if the weight in the font is less than medium which possibly need emboldening -->
  <test compare="less_eq" name="weight">
   <const>medium</const>
  </test>
  <!-- check to see if the pattern requests bold -->
  <test compare="more_eq" name="weight" target="pattern">
   <const>bold</const>
  </test>
  <!--
                  set the embolden flag
                  needed for applications using cairo, e.g. gucharmap, gedit, ...
                -->
  <edit mode="assign" name="embolden">
   <bool>true</bool>
  </edit>
  <!--
                 set weight to bold
                 needed for applications using Xft directly, e.g. Firefox, ...
                -->
  <edit mode="assign" name="weight">
   <const>bold</const>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="hinting">
   <bool>true</bool>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="hintstyle">
   <const>hintslight</const>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="rgba">
   <const>rgb</const>
  </edit>
 </match>
 <dir>~/.local/share/fonts</dir>
 <match target="font">
  <edit mode="assign" name="antialias">
   <bool>true</bool>
  </edit>
 </match>
</fontconfig>

    I tried removing “Synthetic emboldening” here but it doesn’t seem to change anything so I put it back. I also tried removing fonts.conf but it still doesn’t change anything. My gut feeling is that there is a fontconfig config somewhere changing the way Noto Sans CJK is being rendered in KDE/QT. I just couldn’t figure out where or what. The fonts themselves are fine in LibreOffice so I don’t think there’s any issue with the package.

    Now reading through the primer again, I checked the configs in /etc/fonts/conf.d and found all the configs there. There’s a lot so I’ll look through it and see which one might be changing the way CJK is rendered.