From owner-freebsd-gnome@freebsd.org Sat Jun 15 04:08:53 2019 Return-Path: Delivered-To: freebsd-gnome@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A30815BA797 for ; Sat, 15 Jun 2019 04:08:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 176058C0C7 for ; Sat, 15 Jun 2019 04:08:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id CA2B715BA795; Sat, 15 Jun 2019 04:08:52 +0000 (UTC) Delivered-To: gnome@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A62F215BA792 for ; Sat, 15 Jun 2019 04:08:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BCB88C0C4 for ; Sat, 15 Jun 2019 04:08:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 586D86DCB for ; Sat, 15 Jun 2019 04:08:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x5F48peA027397 for ; Sat, 15 Jun 2019 04:08:51 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x5F48pDp027396 for gnome@FreeBSD.org; Sat, 15 Jun 2019 04:08:51 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: gnome@FreeBSD.org Subject: [Bug 238482] www/firefox: 67.0_3,1 print pre-formatting is HORRIBLE Date: Sat, 15 Jun 2019 04:08:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gnome@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: see_also Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2019 04:08:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238482 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=3D2= 257 | |44 --- Comment #13 from Kubilay Kocak --- (In reply to Ronald F. Guilmette from comment #9) Hi Ronald, I add the comment below both as a committer who seeks to improve the user experience as a high priority value, who looks at many many issues and interactions in Bugzilla, and as a member of the FreeBSD Bugmeister team to= who manages issue tracking process in the project. First, I'd like to respectfully request that you please dial down the rheto= ric when using our issue tracker (or any other public project space) in future. I/we understand (very well) that issues can be very frustrating (we report issues in other projects too), particularly if issues do not appear to be treated as importantly or in as timely a manner, as you may feel they are, = or should. Nevertheless, it is prudent in all circumstances to: a) Assume good faith b) Assume in advance there are things we as reporters don't understand or k= now in terms of the context or nuances of issues. Asking (unloaded/good) questi= ons that seek to understand instead of letting our frustrations leak is much mo= re productive. c) Attempt to remain concise, objective and unemotional in the way we communicate. In particular, this means talking about the problem 'out there' from 'the same side' in a collaborative manner, and not contextualising iss= ues in terms of me vs you,users vs maintainers or other potentially adversarial appearing ways. d) For opensource projects, understand that resolving issues is based on the currency of collaboration and positive/constructive influence. Users that understand this tend to receive much more fruitful responses to their reports/concerns, and can save themselves a lot of unnecessary frustration. We all seek to be understood, but in general, it pays to seek first to understand. On the issue of this issue, I'd like to add a few points, and one proposal: 1) On the subject of "Works As Intended", and the "It is in no sense fixed" comment. The only positive (forward moving) resolution type is "FIXED", which means, resolved by way of a specific action taken (in most cases, a commit). All others are "non fix" resolutions, which varying differences. Resolution selection done right is usually is a process of exclusion, not positive selection, and in some cases, there can be overlap, or a not quite right fi= t. Going through our resolution types, none fit more 'closely' than Works As Intended and it is/was the correct choice. This was made also made explicit with the added comment "Bitmap fonts simply don't support anti-aliasing and generally only look good at very low resolutions". Said another way "it looks bad because rendering using bitmap fonts look ba= d" At that point in the issue, there was no specific proposal for a change, wh= ich brings me to=20 2) I propose to change this issue to sounds something like "Make default rendering font not be a bitmap one" Finally, something that must be acknowledged is that font selection is a ve= ry subjective and widely scoped issue that has ramifications for software and = use cases far beyond browser printing. It is in most cases that any default is = not going to satisfy large groups, or many groups for different use cases, and = the more important issue is that font selection ability for users is a) possibl= e b) obvious to users c) easy to do --=20 You are receiving this mail because: You are the assignee for the bug.=