From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id CFA82425CA for ; Sun, 24 Apr 2022 10:07:21 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 700B268B08F; Sun, 24 Apr 2022 13:07:18 +0300 (EEST) Received: from nef.ens.fr (nef2.ens.fr [129.199.96.40]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 1397E68B04B for ; Sun, 24 Apr 2022 13:07:11 +0300 (EEST) X-ENS-nef-client: 129.199.129.80 ( name = phare.normalesup.org ) Received: from phare.normalesup.org (phare.normalesup.org [129.199.129.80]) by nef.ens.fr (8.14.4/1.01.28121999) with ESMTP id 23OA79HL027974 for ; Sun, 24 Apr 2022 12:07:09 +0200 Received: by phare.normalesup.org (Postfix, from userid 1001) id 21D6EE00CF; Sun, 24 Apr 2022 12:07:09 +0200 (CEST) Date: Sun, 24 Apr 2022 12:07:09 +0200 From: Nicolas George To: FFmpeg development discussions and patches Message-ID: References: <291427c1-9428-3895-da3e-0de5ca2fba0f@tiscali.it> MIME-Version: 1.0 In-Reply-To: <291427c1-9428-3895-da3e-0de5ca2fba0f@tiscali.it> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef.ens.fr [129.199.96.32]); Sun, 24 Apr 2022 12:07:09 +0200 (CEST) Subject: Re: [FFmpeg-devel] proposal for a minor change in the behavior of the drawtext filter X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============0888213329021940399==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============0888213329021940399== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FL5vvGBVa+09GCae" Content-Disposition: inline --FL5vvGBVa+09GCae Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Francesco Carusi (12022-04-22): > I'm working on an enhanced version of the drawtext filter and would like = to > discuss with you about a minor change in its behavior related to line > spacing management. > In the current implementation the space between two lines of text is set > equal to the height of the highest glyph found in the text plus the optio= nal > user defined "line_spacing" parameter (which defaults to 0): >=20 > line_height =3D max_glyph_h + line_spacing >=20 > This has some drawbacks: > 1) the line height depends on the text > =A0=A0=A0 See image "line_height-old.png" (the blue lines where added by = me) > =A0=A0=A0 The filter is applied three times with tree slightly different = texts: > the line_spacing parameter was not specified, > =A0=A0=A0 but the actual line height changes due to the different heights= of the > glyphs > 2) the line height is not consistent between the same text being rendered= by > the filter and by external tools >=20 > The proposed change is: > 1) the default line height is set to the font-defined line height > 2) the line_spacing parameter, if specified, sets the actual line height > (line_height =3D line_spacing) > 3) the default value of line_spacing is set to -1 (which means: use the > default line height) >=20 > The image "line_height-new.png" shows the effect of the new behavior. >=20 > Which is the impact of the change? > A) users using the line_spacing parameter would see less space between li= nes > B) users not using the line_spacing parameter would see (in most cases) m= ore > space between lines >=20 > Can the impact be mitigated? > Well, yes, we may add a new parameter named 'line_height' and deprecate > 'line_spacing', in this way anyone using line_spacing explicitly would not > see any change in the filter behavior. I don't like this solution but it = may > help reducing the impact of the change. Hi. While your proposal shows merit in itself, it also feels like the first towards re-inventing a layout engine. The problem with line spacing is the tiniest of drawtext problems: look for right-to-left, ligatures and so much more. If you want to enhance the output of drawtext, I think it would be more efficient to choose a good layout engine library, Libre and portable, and to make it use it optionally. Regards, --=20 Nicolas George --FL5vvGBVa+09GCae Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE6ooRQGBoNzw0KnwPcZVLI8pNxgwFAmJlIUsACgkQcZVLI8pN xgzzTA//YAMC2N5eQqOGNud4B5AZainxbnChkC7haPa0QdREjYFl+/SEEpd4omKo MOcVOio/6bbTr7aM/yQgn8/i+duu27CPnaQD/QIn+cIKcokPJW9Tpp0NFc4ERTgU 992d4QRT9IXP1mQSySPGeNBzt+yfLT4qJQqEauRSHhm5vZGlsm1KKB/PnAPJeyk6 +VNlUfEh+tMRhV6krSdyIsdbu6KPnmr7fK27BA2vTHIqyfkVsjOmSM5vjMENMwG8 A7Z8lz5oXy7ps7ExQAGQGZ0AfzTZ50eYWj1Iz5jZ1wvkdmagdm+UKWlV4clY1/Q/ AnfhNeF/eosRBPebnSssi6RQWkjOKtOIuqt7wE3oL0sfC5yjnsNjZpug/3vn/sgY sy/PckMcNlomR6zmdYS2RW1zmKJKrRUzLBgCkwX79H2SWSgTxAgFD+eZt4M8r1B1 BqWQ6bGDRe9dAXTFeFHcOnbZyYbTx55ogcG5KJHKE6l5HkhrQJtPaqket2iBvV3H 9Wid/d/ndkEjuXY7MZdsQpLn4gwPOrz0zws/Ndswm54hM73H5L6B22NNW/kaU8vw 4a4i3tEVne2ccv2ZRMlOdQpIgn26YkCJdx/oPyN40mHY/UPMLsxE2t4qhOHFBQns Ex6elHQ7dNwg73hlozDRJ0V/P0NJ7/yoxufmNekh1i+XwSTGxOY= =xc/n -----END PGP SIGNATURE----- --FL5vvGBVa+09GCae-- --===============0888213329021940399== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". --===============0888213329021940399==--