@sirocyl Does this fix your issue? if yes, I can help in landing

On it, thank you!

My friend, I think you are affected by this change, and this applies to whatever PHP version

I super-like the result of this in /project/manage/1/, so approved.

I'm on the latest pull, commit f81e821abf2b275d1778d02a018a4d0af7208be8.
A bit off topic here :) but I'll quickly sum up the issue I'm having (and am in the middle of trying things to fix):

• Visiting https://[phorge instance]/auth/config/view/2/, where my Github auth item is, makes nginx dump a blank 502 page, no further info.
• First instinct is to check the /var/log/nginx/error.log, where I get a PHP stack trace concatenated into one line, and an nginx header length error (reformatted for readability. the PHP error is truncated):

Oh, totally possible that I forgot to update it :)

(@speck red light)

Whops, forgot to approve this. Sorry! And thanks.

I'll take your word on it that it's supported, though the current installation guide says otherwise.
Further, I had a few roadbumps on a fresh install to a new server with PHP 8, that I suspect may relate to strlen(NULL) behavior, but I did need to set up PHP 7 to make sure that was or wasn't the case.
(I'm in the process of reproducing those and working out a possible cause or trace. Some manifested as warning banners, one as a 502 on my end in the GitHub auth provider.)

We already support PHP 8...

Agreed. We should not link fonts from outside our own assets (those hosted on an instance of Phorge.) I don't think I suggested that, but I don't disagree.

maybe include "allow extensions to provide themes" here...

We should pack the fonts internally, not use an external source.
We pack all the assets we use, for cases where network access is limited by infosec types or by other reasons.
Just serving few font files from the site would be much simpler, and the extra bandwidth requirements are miniscule anyway.

As far as bold/italic variants are concerned, for fonts that support it, you can preferentially serve the "variable" version and only fall back on specific font variants when that isn't supported, to save on bandwidth in most cases - since the e.g., Inter Variable font file "includes" the bold and italic, condensed and expanded versions, essentially "for free", as they're generated by the font engine/renderer on the fly from the base font.

In T15630#15618, @aklapper wrote:

For consideration of the bigger picture, I'd like to mention https://collinmbarrett.com/block-web-fonts (performance etc) and for example Firefox 118+ blocking font fingerprinting in private windows (yes, private only, but I can vaguely imagine expansion).

Inter and Noto look best to me (1080p laptop screen, Linux, Firefox, no scaling) given all default sizings in Phorge (as a drop-in replacement). Noto, I believe has a lot more Unicode symbol coverage, and a larger file size as a result; but Inter has variable font properties (e.g., more weights than "bold" and "regular", as well as condensed and expanded forms, letter variants for differentiating I/l O/0, etc).

For consideration of the bigger picture, I'd like to mention https://collinmbarrett.com/block-web-fonts (performance etc) and for example Firefox 118+ blocking font fingerprinting in private windows (yes, private only, but I can vaguely imagine expansion).

Broader CSS discussion: T15734

A mermaid-js one could be written based on the old graphviz one:

In T15673#15587, @valerio.bozzolan wrote:

TRUST ME - YOU DON'T WANT TO LISTEN MY ENGLISH :D :D

Btw now the video is here :D :D AGAIN SORRY PHORGE FOR MY MISTAKES <3 <3

TRUST ME - YOU DON'T WANT TO LISTEN MY ENGLISH :D :D

Nice! Is there a recording of the talk?

Nice, you touched on most of the advantages of Phorge. It really does have some strong competitive advantages.

From my perspective, on Linux, Phorge already supports configurable fonts - that is, none of the specific typefaces mentioned in the phorge css actually work, so it falls back to whatever I set as the default document font in Gnome.

In T15630#15574, @sirocyl wrote:

CSS is rather flexible now; a larger font scale can be specified for displays above a certain horizontal resolution or display width/effective character width, nowadays.
Atkinson looks poor at the font size specified, you're right about that @bekay.
I feel like it might need to break out into another task item, but perhaps CSS modernization is imo a good step towards making Phorge more compatible and capable, on screens both small and large.

In T15630#15574, @sirocyl wrote:

As far as fonts are concerned, while we should decide on a new default font, should this be a configurable? Should we make an item (in Config for defaults, and in Settings for users' choice) to change the UI font on an installation?

As far as fonts are concerned, while we should decide on a new default font, should this be a configurable? Should we make an item (in Config for defaults, and in Settings for users' choice) to change the UI font on an installation?

CSS is rather flexible now; a larger font scale can be specified for displays above a certain horizontal resolution or display width/effective character width, nowadays.
Atkinson looks poor at the font size specified, you're right about that @bekay.
I feel like it might need to break out into another task item, but perhaps CSS modernization is imo a good step towards making Phorge more compatible and capable, on screens both small and large.

I haven’t run this specific issue but I have seen other oddities when using my installed arc within the arc or phorge repos. I’m unable to get it to work unless I use the arc that exists along side that phorge repo. That might be similar here.

Hahaha I’m just now seeing this. Thank you for putting together the presentation and giving the talk. I enjoy seeing your excitement!

I configure my browsers to increase the default font size because my eyes can’t handle the small fonts. Most pages tend to size appropriately but there are some oddities, including Phorge. I’ll grab some screen caps when I’m back on workstation.

I am honestly surprised by the notion, the user base of phorge is still using old, small or low resolution screens. I always thought this project was catered towards tech-savvy devs and/or corporations and will be used in contexts where a FullHD screen is the default case. Maybe we should sharpen our target audience 😅

I am honestly happy that you have the privilege to afford getting bigger screens. Unfortunately not everyone has. The point I'm trying to make is: There may be valid + good reasons to increase font sizes, absolutely. However, "go with the time" and "times have changed" phrases are neither valid reasons nor argumentations. :)

In T15630#15566, @aklapper wrote:

In T15630#15561, @bekay wrote:

Times have changed and we all have very big screens.

Absolutely not. Maybe in some richer countries to some extent, but not on my mobile phone. (And even if that was true, scaling exists for a reason.)

In T15630#15561, @bekay wrote:

Times have changed and we all have very big screens.

Thanks for all the tips <3 <3

And on another note: Times have changed and we all have very big screens. I think we should increase the default font size of 13px to 14px. It is about time...

In T15630#15553, @sirocyl wrote:

Of these, I like 1 and 3 (Noto and Inter) better. How does Atkinson look? (I haven't gotten around to changing the font on my end yet, heh)

Of these, I like 1 and 3 (Noto and Inter) better. How does Atkinson look? (I haven't gotten around to changing the font on my end yet, heh)

Here you can see the fonts with Phorge itself. For me the clear winner is Noto Sans. It can add some real modern style to the site.

I like the first three the most.

Maybe I should create a slowvote poll to reach a decision?

Regardless of the choice made here; I'm likely going to maintain a patch on my instance that uses Inter for headings and UI elements, and Atkinson Hyperlegible for long-form text prose content.

Thanks for this! BTW you are now in the family of Trusted Contributors - feel free to escalate as a Task under Bug Reports at least I think and maybe Remarkup I think. (You can do this with a manual copy-paste and we can close this as obsolete)

I've used phorge-devcontainer as well and it works great!

Testing if "Foist Upon" does what I hope it does

@avivey Much cleaner and also works as expected (just tested). Thanks for finding that better approach! Now how can I approve your patch as I'm still set as original author, sigh?

Both of these failures are edge cases so it does seem likely we wouldn't have found them as quickly. I do still wonder how many Windows users we have.

To be fair, it's possible that most of the arc features work for Windows users that don't use PHP. Or at least, arc diff might work for some setup of lint/unit configuration.

The ArcanistBundleTestCase failures are due to diff binary not being present on Windows systems. The tests could be rewritten to utilize git diff instead but would take some effort.

Fix some lints about line length