Terminal: 機能のリクエスト：sixelグラフィックのサポート

Sixelを実装する際には、透明度を含む画像でテストすることが重要です。
透明度は、異なる色のピクセルを描画することで実現できますが、シクセルカラーのいずれかで一部のピクセルを描画せず、背景色をそのままにします。
これが非長方形のシクセルを適切に描画する唯一の方法であり、新しいWindowsターミナルの背景のアクリルの透明度で特に便利だと思います。

たとえば、UbuntuでWSLを使用してテストすると、mltermでは、このような画像は透明マスクを使用して適切にレンダリングされ、背景色は保持されますが、xterm -ti vt340では、背景が白であるにもかかわらず、手つかずのピクセルが黒で描画されます。ターミナルウィンドウにブリットする前に、透明マスクまたはアルファなしで黒として初期化されたメモリビットマップで6つのエルをレンダリングすることを意味します。

ああ。 Sixelはとてもクールなものです。

私はそれが必要だと決めました。 必要。

私は喜んでPRをレビューします:)

このリクエストに言及したBuild2019のインタビューを今日キャッチしました。 私はまだsixelのXorgがちょうど間違っていると主張します。 だから_非常に間違っている_。

ffmpeg-sixelの「SteveBallmerSellsCS50」デモは決して飽きることがありません。 お奨めは、ビデオが音を欠いていることは少し残念です（音は本当にビデオを作ります）。 当然のことながら、コンソールにはすでに音があります。 彼らは完全にビープ音を鳴らします。 前例セット。 私たちが本当に_必要とする_のは、フレーム、アミライトとインターリーブされたオーパスクリップの新しいCSIシーケンスですか？

ケン、私はシクセルに言及するためにこれに本当に値する;）

差出人： [email protected]
送信日：2019年5月8日水曜日16:31:31
宛先：microsoft / Terminal
Cc：購読済み
件名：Re：[マイクロソフト/ターミナル] Sixelグラフィックサポート（＃448）

ビルド2019をキャッチhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmybuild.techcommunity.microsoft.com%2Fhome%23top-anchor&data=01%7C01%7Cduhowett%40microsoft.com ％7C81f48be19f374665cd3408d6d40d4dc6％7C72f988bf86f141af91ab2d7cd011db47％7C1＆sdata = i8rfPCaN％2FxqdF％2F4qRtdN2Py4％2BVRlbPgpwJWtPZSGGHc％3 私はまだ、sixel上のXorgが間違っていると主張していますhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FWSL%2Fissues%2F1099%23issuecomment-248513013&data=01 ％7C01％7Cduhowett％40microsoft.com％7C81f48be19f374665cd3408d6d40d4dc6％7C72f988bf86f141af91ab2d7cd011db47％7C1＆sdata = J％2BwCnn0z70FkI9lDcus1nMXcKz1P0ArL％2 とても非常に間違っています。

ffmpeg-sixel https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsaitoha%2FFFmpeg-SIXEL&data=01%7C01%7Cduhowett%40microsoft.com%7C81f48be19f374665cd3408d6d40d4 ％7C1＆sdata = G％2F9mvw1EdADkwChSbHZ％2FI54k9xvXagV％2FxD9VbJtyw7g％3D＆reserved = 0 "Steve Ballmer SellsCS50"デモhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F 2Fwatch％3Fv％3D7z6lo4aq6zc％26feature％3Dyoutu.be＆データ= 01パーセント7C01％7Cduhowett％40microsoft.com％7C81f48be19f374665cd3408d6d40d4dc6％7C72f988bf86f141af91ab2d7cd011db47％7C1＆SDATA = 6IVwBHs6％2F43rXdk6GabiSUpTFS86xUGB6bubfkS3ea0％3D＆予約= 0は疲れてカントーを得ることはありません。 お奨めは、ビデオに音がないのは少し残念です（音は本当にビデオをhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fvにしますhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FANSI_escape_code%23CSI_sequences&data=01%7C01%7Cduhowett% 40microsoft.com%7C81f48be19f374665cd3408d6d40d4dc6%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=29pJq5661TXtnn2huLyUMgebTyYMEhTKXpAm19jzqHU%3D&reserved=0 for the

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してくださいhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FTerminal%2Fissues%2F448%23issuecomment-490688164&data=01 ％7C01％7Cduhowett％40microsoft.com％7C81f48be19f374665cd3408d6d40d4dc6％7C72f988bf86f141af91ab2d7cd011db47％7C1＆SDATA = pnXPvsuGF7l5mQfU2htzFwJnqZjEuW4zNuh1HaBJnKM％3D＆予約= 0 、またはスレッドミュートhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithubを。 COM％2Fnotifications％2Funsubscribe-AUTH％2FADNHLGXQOYKINZMIBKTB4LTPUNPFHANCNFSM4HLENFOQ＆データ= 0.01％7C01％7Cduhowett％40microsoft.com％7C81f48be19f374665cd3408d6d40d4dc6％7C72f988bf86f141af91ab2d7cd011db47％7C1＆SDATA =％2F4pMmm7bvPa％2BbFmE1gyN8％2BoTZDKJyRksBrkJpDh％2BLug％3D＆= 0予約。

関連：＃120

必要。

笑私はストリームを見ていましたが、「スタジオの観客の前でライブで仕事を割り当ててくれる上司がいます」と思いました。

これをv1.0の優先事項にしてください！

3Dアニメーションはv1.5にすることができます😛

ああ、神様

この要求に賛成することで、シクセルズはターミナルにいるのはとても素晴らしいことでしょう。

今週末、MITライセンスのJavaベースのTUIライブラリのsixel読み取りサポートの実装を終了しましたが、驚くほど簡単でした。 sixelデータの文字列をビットマップイメージに変換するコードはここにあり、Sixelクラスのクライアントコードはここにあります。

デコーダーのパフォーマンスについてはほとんど何もしていません。 ただし、Swingバックエンドを使用する場合は、ここに示すように、パフォーマンスは引き続き問題ありません。 （ヘビの画像は、ビザンツがデモgifを作成するために貧弱なパレットを使用したためにのみ見栄えが悪くなります。）私は、それがどれほど速くまとめられたかに少し驚いていました。 「sixelをビットマップにデコードする」部分は簡単なビットであり、難しいビットは「画像データをテキストセルに貼り付け、それが存在する場合は画像を文字ではなく画面にブリットする」と言っても過言ではありません。

sixelのターミナルサポートに興味のある他の人々にそれを伝えたいだけで、それがあなたを助けることができることを願っています。

他の誰かがJupyterノートブッククライアントを作成した場合は賛成します;）

C（副Java）で書かれたminttyでのSixelサポートの例はすでにあります。 必要なのは、C ++へのリファクタリングだけです（少なくとも初期サポートの場合）。 それでも、他のプロジェクトでどのように実装されているかを確認するのは常に良いことです。

C（副Java）で書かれたminttyでのSixelサポートの例はすでにあります。 必要なのは、C ++へのリファクタリングだけです（少なくとも初期サポートの場合）。 それでも、他のプロジェクトでどのように実装されているかを確認するのは常に良いことです。

minttyのライセンス（GPLv3以降）に問題はありますか？

https://github.com/mintty/mintty/blob/master/LICENSE

https://github.com/mintty/mintty/blob/master/LICENSE

そのリンクから：

Sixelコード（sixel.c）は、minttyのようにGPLの下で再ライセンスされます。
著者の許可（kmiya @ culti）

その正確なコードをC++に音訳する場合、派生物は、その条件に従ってGPLv3以降のライセンスを取得するか、まったく配布しない必要があります。 （kmiya @cultiに、別のライセンスでsixel.cを提供する意思があるかどうか、または他のライセンスで利用可能であったかどうかを尋ねることもできます。そのソースからコピーを見つけてください。）

Windows Terminalに含めることが許容されるかどうかはわかりません。WindowsTerminalを一目見ただけで、MITライセンスであることがわかります。したがって、minttyのGPLv3 + sixel.cの直接の子孫を使用してリンク/ロードする方法によっては、ライセンスの問題に。

とにかく、ここで他の誰かのプロジェクトを盗聴して申し訳ありません、今洞窟に戻って...

Windows/Linux用のC/C ++で記述されたsixel対応の控えめなターミナルエミュレータウィジェットがあり、使用できるSixelRendererクラスがあり（ある程度の最適化が必要ですが）、BSD-3ライセンスがあります。 おそらくその最大の欠点は、特定のC++フレームワーク用に作成されていることです。 それでも、IMOのSixelRendererのコードは、ほとんど労力をかけずに翻訳可能です。 （私はその作者なので、これを知っています。:)）

https://github.com/ismail-yilmaz/upp-components/tree/master/CtrlLib/Terminal

Sixelを実装する際には、透明度を含む画像でテストすることが重要です。
透明度は、異なる色のピクセルを描画することで実現できますが、シクセルカラーのいずれかで一部のピクセルを描画せず、背景色をそのままにします。
これが非長方形のシクセルを適切に描画する唯一の方法であり、新しいWindowsターミナルの背景のアクリルの透明度で特に便利だと思います。

たとえば、UbuntuでWSLを使用してテストすると、mltermでは、このような画像は透明マスクを使用して適切にレンダリングされ、背景色は保持されますが、xterm -ti vt340では、背景が白であるにもかかわらず、手つかずのピクセルが黒で描画されます。ターミナルウィンドウにブリットする前に、透明マスクまたはアルファなしで黒として初期化されたメモリビットマップで6つのエルをレンダリングすることを意味します。

うーん。 私が目の前にいるVT340は、DCSP1のP2パラメーターを尊重します。 P2; P3; qSIXELシーケンスを開始するシーケンス。 一方、Xtermはそれを無視しているようです。 ただし、ラスター属性シーケンス（ "Pan; Pad; Ph; Pv）を使用して高さと幅を指定すると、背景がクリアされるため、黒いピクセルが得られます。

ttwinエミュレーターの無料試用版を入手して、VT340およびVT340として機能するXtermとの動作の違いを確認することを考えていました。

しかし...一般的にSIXELをサポートするという考えについては+1、互換性テストを考え出すという考えについては+10。

そこに着いたら、iTerm2インラインイメージプロトコルのサポートを追加できます...少なくとも実装は簡単なはずです。イメージへのパスだけが必要で、すべてを独自に実行します。

私が両方のシステムで持っている1つの疑問は、アラインメントで何が起こるかということです。 画像の幅または高さが文字の幅または高さの倍数である場合はすべて問題ありませんが、そうでない場合は、下側と右側にのみパディングを追加する必要がありますか、それとも画像を中央に配置してすべての側にパディングを追加する必要がありますか？

ちょっとここに研究のためのいくつかの関連するリンクがあります：

• terminal-wgの「優れたイメージプロトコルの基本」 （およびリンクされた以前のディスカッション）
• Sixelサポートについてのこの大規模なスレッド

そこに着いたら、iTerm2インラインイメージプロトコルのサポートを追加できます...少なくとも実装は簡単なはずです。イメージへのパスだけが必要で、すべてを独自に実行します。

それはおそらく別の仕事になるはずです。 SixelとReGISは、明示的に帯域内のグラフィックデータまたは文字データ用です。 それが悪い考えだと言っているのではなく、別の機能として扱われるべきだと言っているだけです。

私が両方のシステムで持っている1つの疑問は、アラインメントで何が起こるかということです。 画像の幅または高さが文字の幅または高さの倍数である場合はすべて問題ありませんが、そうでない場合は、下側と右側にのみパディングを追加する必要がありますか、それとも画像を中央に配置してすべての側にパディングを追加する必要がありますか？

SixelとReGISのグラフィックデータの配置については、さまざまなマニュアルで（不十分に）説明されています。 Sixel画像は、文字セルの境界に配置されます。 画像の周囲に黒い境界線が必要な場合は、それらの黒いピクセルを自分で追加する必要があります。 HTMLのマージンやパディングのような概念はありません。 sixelデータの各行は、6ピクセルの高さのストライプを表します。 ターミナルエミュレータでsixel画像データをテキスト文字に揃えようとしている場合、sixelデータを生成するソフトウェアが各文字のグリフの高さを認識していない可能性があるため、これはイライラする可能性があります。 古い学校のxtermが手元にある場合は、vt340モードで起動し、さまざまなフォントサイズを指定して（さまざまな文字セルサイズを提供するため）、画像データをテキストに揃えようとする6つのデータを印刷することでこれを確認できます。データ。 （これは、フォントサーバーに96DPIを使用するように指示し、15ポイントのフォントを指定すると正しく見える簡単なテストファイルです。フォントサイズを変更すると、画像がテキストとの位置合わせから外れることが多くなります。https：//gist.github。 com / OhMeadhbh / 3d63f8b8aa4080d4de40586ffff819de）

（もちろん）端末の電源を入れたときにフォントサイズを指定できなかったため、元のvt340ではこの問題は発生しませんでした。

その画像からわかるもう1つのことは、sixelのドキュメントで十分に説明されていないことです。これは、sixelデータの行を印刷すると、画像データの「仮想左マージン」が確立されることです。 '$'または'-'文字を使用してCRまたはCRLFと道徳的に同等のことを行う場合、次の行は、端末の左側の実際の左マージンではなく、この仮想左マージンを基準にして印刷されます。

お役に立てれば。

最後にスクロールして戻ってこれを読んでください。 返信が遅くなってすみません。

たとえば、UbuntuでWSLを使用してテストすると、mltermでは、このような画像は透明マスクを使用して適切にレンダリングされ、背景色は保持されますが、xterm -ti vt340では、背景が白であるにもかかわらず、手つかずのピクセルが黒で描画されます。ターミナルウィンドウにブリットする前に、透明マスクまたはアルファなしで黒として初期化されたメモリビットマップで6つのエルをレンダリングすることを意味します。

xtermで透明性をサポートするのはそれほど難しいことではありません。 私は他の理由でコードを掘り下げてきました。 誰かがXtermのこの動作に依存しているのではないかと心配しているので、互換性フラグの後ろに置くことをお勧めします。これも簡単なはずです。 しかし、デフォルト値の問題があります。 デフォルトは何ですか？ 黒または透明。

元のVT240、241、330、および340が何をしたか知っていますか？ 実際のVTの経験を忠実に表現しようとすることを提案できますかデフォルトの動作として？ これをテストするには、反転したスペース文字を印刷し、その上に6つのグラフィックを重ねて、指定されていないピクセルがどのような色でレンダリングされるかを確認します。

XtermがVT340をエミュレートするように動作する機能がある限り、msft端末のデフォルトが何であるかを気にしすぎているかどうかはわかりません。 ターミナルでsshを介してログラインを実行するために作成したコードは、上記の「指定されていないピクセルは黒」の動作を前提としています。 この変更を行う場合は、そのコードを書き直す必要があります。

ターミナルエミュレータでsixel画像データをテキスト文字に揃えようとしている場合、sixelデータを生成するソフトウェアが各文字のグリフの高さを認識していない可能性があるため、これはイライラする可能性があります。

（もちろん）端末の電源を入れたときにフォントサイズを指定できなかったため、元のvt340ではこの問題は発生しませんでした。

端末エミュレーターが、元のDEC端末の動作に正確に一致するように画像を拡大縮小できなかった理由はありますか？ したがって、VT340の行の高さが20ピクセルの場合、高さが200ピクセルの画像は、フォントサイズに関係なく、正確に10行をカバーする必要があります。 それは、ターミナルエミュレータのポイントの一種であるレガシーソフトウェアと合理的に互換性を保つことができる唯一の方法のように思えます。

その動作を拡張して画像をより高い解像度でレンダリングしたいことは理解できますが、それはオプションの拡張であると思います（または既存の独自形式の1つを使用するだけです）。 したがって、理想的には、Sixelのデフォルトを、実際のDEC端末で得られるものにできるだけ近づけたいと思います。

ちょっとここに研究のためのいくつかの関連するリンクがあります：
terminal-wgの「優れた画像プロトコルの基本」

Sixelは、ペインを並べたtmuxでサポートできないため、壊れています。

ある程度の作業（実際には多くの作業）が必要でしたが、sixelを使用すると、「端末内の画像」のトリックのほぼすべてを実行できます。

• ターミナル内のレイヤー化されたセルごとのマスクされた画像： https ：//jexer.sourceforge.io/images/sixel_many_images.png

• VT100スタイルの倍幅サポートにsixelを使用している端末のフローティング（多重化）端末ウィンドウ： https ：//jexer.sourceforge.io/screenshots/jexer_sixel_in_sixel.png

• 画像付きの「tmuxスタイル」タイル端末： https ：//gitlab.com/klamonte/jexer/-/wikis/uploads/7603381f82414ef9ae214bfcf759c064/example_tilingwm2_1.png

• 同じプロットを示す異なるテキストセルサイズのマルチヘッド共有ターミナルセッション： https ：//jexer.sourceforge.io/screenshots/multiscreen_2b.png

• メイン端末のフォントに存在しないCJKと絵文字をレンダリングするためのsixelの使用： https ：//jexer.sourceforge.io/screenshots/xterm_sixel_cjk.png

参照されている「良い」プロトコルスレッドに、興味深いと思われる他のコメントをいくつか含めました。

何といっても、sixelは、画像とテキストが混在する端末側のインフラストラクチャを構築するための優れた足がかりです。 直接の経験から言えば、端末側（画像の保存/表示）はマルチプレクサ/アプリケーション側（tmux / mc et al）の約1/4の硬さです。

sixelsは、インバンドグラフィックス（たとえば、ssh経由）の理想的なソリューションです。既存の多くのツールでサポートされているため、外出先でタイムスタンプ同期の問題をプロットするなどの実用的な目的ですぐに使用できます。

therealkencによって示され、640292222のklamonteによってさらに説明されているように、すべてを6枚の画像で処理できますが、画像を並べて表示することもできますが、ある程度の作業が必要です。

しばらく前、私はtmuxのフォールバックモードで他の数人と協力し、高度なUnicodeグラフィックを使用して、sixelをサポートしていない端末でsixelイメージを表現していました。

これは自動化されたANSIIアートに少し似ており、ほとんどのフォントに存在する特殊なブロック文字を利用しています。この同等の色のUnicode表現は、sixelの代わりに使用でき、後で実際のsixel画像で上書きできます（または上書きできません）。 また、すべての6枚の画像をスクロールバック用に保持するという問題も解決します。これは、忠実度の低いUnicodeプレースホルダー（メモリを節約するためなど）に置き換え、何らかの理由で表示できない場合に6枚の画像のプレースホルダーを使用することによって行われます。

コードはパブリックドメインでした。 これは、sixelサポートへの最初のステップとしてすぐに使用できます。

• sixelsシーケンスが送信されたことを検出し、Unicodeテキスト置換を計算します

• このユニコードシーケンスを表示します。これは、Windowsターミナルですでにサポートされています。

• 後で、sixelが実装されたら、sixelシーケンスの上にレンダリングします。

興味がありますか？

ところで、私はここで私のおなじみのgnuplot x ^ 2 sinと10sin（x）プロットを認識していますそれがいくつかのインスピレーションを提供してくれてうれしいです😄

お願いします。

@DHowett acac350は、実際にシクセルグラフィックスをレンダリングするための最初のステップですか？ sshを使用していて、 lsixプログラムを使用してイメージのディレクトリを表示したいという人々から、Microsoftターミナルでのsixelサポートの要求を受け取っています。

ソータ。 これで、着信DCSシーケンスを処理できるようになりました。 ハンドラーはまだ接続していませんが、接続するためのインフラストラクチャを用意することは非常に重要でした。 ：笑顔：

ここにいくつかの更新があります。 ここに作業ブランチがあります。 初期のスクリーンショットは次のようになります。

私が当初考えていたのとは反対に、sixel画像をレンダリングする上で最も難しい部分は、実際にはconptyレイヤーです。 Sixel画像はインラインオブジェクトであると想定されています。 sixel画像のレンダリングは、文字のレンダリングサイズによって異なります。 ただし、余分なconptyレイヤーが原因で、sixelシーケンスを処理するときに文字のレンダリングサイズを実際に取得することはできません。 これは非常に抽象的で曖昧に聞こえます。 これに興味がある人は誰でも私のブランチをチェックアウトして、それがどのように行われるかを見ることができます。

全体として、conptyレイヤーは、sixel画像のスクロールとサイズ変更の処理を非常に困難にします。 私のブランチでは、表示するだけでよい場合に機能します。 しかし、スクロールとサイズ変更の両方が完全に壊れています。

まだ調べていませんが、パススルーモードを使用してターミナル自体に実装できますか？ それでもOpenConsoleに追加しますが、コードを共有することはできないようです。 ある時点でWindowsターミナルをOpenConsoleから切り離す必要があるため、両方のコードを単純に複製することをお勧めします。 また、パラメータのあなたとj4james PRに基づいていますか？ それも役立つでしょう。

@WSLUserご清聴ありがとうございました。 このスクリーンショットは、実際には、j4jamesの素晴らしいパラメータPRが存在しない約1か月前のものです。 私の仕事は完全にWindowsターミナル内にあり、コンホストではありません。 私はこのPRを社内でコンソールチームに見せ、それ以来ある程度の進歩を遂げました。 しかし、私はconptyの問題のために立ち往生しています。

ええ、マスターからリベースして、https：//github.com/microsoft/terminal/pull/7578とhttps://github.com/microsoft/terminal/pull/7799を追加します。 そこから、パススルーモードのConPTYに何が欠けているかを確認できます。 MinttyはConPTYモードにパススルーを使用しているのだろうか。

MinttyはConPTYモードにパススルーを使用しているのだろうか。

minttyがconptyをまったく使用していないことは確かです😜

ここでのconptyの秘訣は、接続されたターミナルから誤ってコンテンツをクリアしないように、コンソール（conpty）が6つのコンテンツで満たされたセルについて知る必要があることです。 たぶん、conptyは、サイズの大きいグラフィックでセルをペイントすることを無視し、接続されたターミナルがそれらのセルをそのままにしておくと想定するように啓発される可能性があります。

これにより、最適化の一部が台無しになる可能性があります（たとえば、sixelデータを含む行を消去できないなど）が、十分に開始できる可能性があります。

\

たぶん、conptyは、サイズの大きいグラフィックでセルをペイントすることを無視し、接続されたターミナルがそれらのセルをそのままにしておくと想定するように啓発される可能性があります。

これは私の当初の計画でもあり、現在のconptyアーキテクチャでは最善の解決策かもしれませんが、いくつかの問題があります。

1. これはDCSストリーミングとどのように相互作用しますか（まだ解決策がないと思います）。 conhostバッファーに送信されると同時に、バイトストリームをconptyに渡す、ある種の分割ストリームの概念が必要だと思いますが、それはプロセスに多くの不要なオーバーヘッドを追加するようです。
2. これは、conpty端末のピクセルセルサイズがわかっている場合にのみ機能します。 Sixelの最善の解決策は、元のVT端末のセルサイズと一致させることであると前に述べましたが、そうしていれば、これは問題にはなりません。 ただし、私が知る限り、他のターミナルエミュレーターはそれを実行しないため、他のユーザーとは連携しません。

@ j4jamesが提起した2番目の問題は、フォントの違い、フォントサイズの違い、フォントのサイズ変更を考慮すると、さらに複雑になります。 したがって、一般的に、この問題には3つの側面があると思います。

• 最初のconptyは、sixelコンテンツで満たされたセルについて知る必要があります。これがないと、conptyのバッキングバッファーとWTの描画バッファーが必然的に同期しなくなります。
• これを行うには、conptyは描画コンテキストでピクセルセルサイズを知る必要があります。これは、WTの描画レイヤーによって処理されます。 conptyと実際のDXRendererの間には大きなギャップがあり、これを困難な作業にします。
• また、フォントやフォントサイズが変わると、それに応じてシクセル画像も変わるのが理想的です。
• そして最後に、ペイン、代替バッファ、差分描画、スクロールなどの他のものを処理します。

@ j4jamesが提起した2番目の問題は、フォントの違い、フォントサイズの違い、フォントのサイズ変更を考慮すると、さらに複雑になります。 したがって、一般的に、この問題には3つの側面があると思います。

明確にするために、私のポイントは、VT340の動作と正確に一致していれば、それは問題にならないということでした。したがって、フォントサイズに関係なく、10x20ピクセルの画像は正確に1文字のセルを占有します。 これは、他のターミナルエミュレーターの動作と一致させたい場合にのみ問題になります。これは、後で使用できるオプションである可能性があります。 このアプローチにはまだ問題がありますが、個人的にはそれほど問題ではないと思います。

私のより大きな懸念は、DCSストリーミングの問題を無視しているように見えることです。これにより、ソリューションのアーキテクチャが根本的に変わる可能性があります。 私が見たいと思うステップは次のとおりです。1。＃7316を解決します。 2.セルのピクセルサイズの解決策について合意します。 3.コンホストで何かが機能するようにします。 4. conhostですべての合併症が解決されたら、それをconptyでどのように機能させるかを検討します。

DCSストリーミングの問題を残して申し訳ありません。 現在の実装では、文字列全体を保存してエンジンに渡すだけです。 これにより、シーケンスが大きい場合にパフォーマンスの問題が発生します。 しかし、少なくともそれは機能します。 したがって、上記の私のコメントは主にそれに基づいています。

しかし、あなたは正しいです。 DCSストリーミングの問題は、他の誰かがこれに手を汚したい場合、実際には最優先事項です。

获取OutlookforiOS https://aka.ms/o0ukef

https://github.com/microsoft/terminal/issues/57での議論によると、conptyはフォントをまったく気にしないと思いましたか？

サイズ変更を行う最も自然な方法は、画像が到着したら画像を文字セルに「アンカーダウン」し、アンカージオメトリに基づいて画像サイズを再計算することだと思います。 それ以外の場合は、画像セルと文字セルで不整合が発生します。

@yatliはい。 それはまた、問題をトリッキーにするものです。

10x20ピクセルの画像は、正確に1つの文字セルを占有します

残念ながら、少なくとも私の現在のフォント設定では、これは間違っています。

間違っている場合は訂正してください。ただし、ピクセルパーフェクトな画像表示を行うには、フォントを気にする必要があると思います。

@skyline75489plsは「アンカー」についての私の更新されたコメントを参照してください

セルのデータ構造はchar | sixel anchorとして更新する必要があります

sixelアンカーには、以下に関する情報が含まれている必要があります。

• 画像オブジェクトへのポインタ
• 浮動小数点数で占めるcharセル領域（例：5.2行x 7.8列）

それは良い考えですが、conptyレイヤーでの余分な翻訳のために、実装の詳細は私を殺しました。 電子メールで人々にスパムを送信することを避けるために、興味があればTeams @yatliで私に連絡してください。

10x20ピクセルの画像は、正確に1つの文字セルを占有します

残念ながら、少なくとも私の現在のフォント設定では、これは間違っています。

私が提案しているのは、あなたがそうするべきだということです。 10x20ピクセルの画像を作成し、それを実際のDEC VT320端末に出力する場合、正確に1文字を使用します（少なくとも80列モードでは）。 したがって、その端末をエミュレートしようとしている場合は、同じことを行う必要があります。 現在のフォントがたまたま30x60の場合は、画像を拡大する必要があります。 フォントが小さい場合は、画像を縮小します。

これにより、任意のフォントサイズでSixel画像を出力でき、常に同じレイアウトを取得できることが保証されます。 画面の特定の領域をカバーする場合、またはテキスト文字でその周囲に境界線を描画する場合は、画像が占めるスペースを正確に把握できます。

間違っている場合は訂正してください。ただし、ピクセルパーフェクトな画像表示を行うには、フォントを気にする必要があると思います。

この方法で「ピクセルパーフェクト」な画像を取得することはないのは事実ですが、それが主な目標ではないと思います。 最近のコンピューターの多くは、画像を拡大するのが日常的な高dpiディスプレイを備えているため、これが奇妙な概念であるとは限りません。 また、ユーザーがフォントサイズを変更したときにレイアウトの一貫性を維持したい場合は、とにかくある時点で画像を拡大縮小する必要があるため、最初からそれを実行して、予測可能なすべての利点を活用することをお勧めします。サイズ。

そしてもちろん、この方法で物事を行うことの他の利点は、それがconptyよりも実行可能に実装できることです。 画像が占める領域がフォントサイズに依存している場合、どうすればconptyを機能させることができるかわかりませんが、これはおそらくわかりません。

このアプローチにマイナス面がないふりをするつもりはありませんが、プラス面がマイナス面を上回っていると思います。

フォントのアスペクト比が10:20と異なる場合はどうなりますか？

フォントのアスペクト比が10:20と異なる場合はどうなりますか？

ターミナルエミュレータのインラインイメージに関する一般的な問題について、この長い、そしてやや「残忍な」議論を読むことをお勧めします。

それはあなたに一般的な考えを与えることができます。

よろしくお願いします

フォントのアスペクト比が10:20と異なる場合はどうなりますか？

画像は少し引き伸ばされたり押しつぶされたりするかもしれませんが、それが世界の終わりではないと思います。

実際の例でデモンストレーションしましょう。 私がボンドの悪役であり、フロントエンドとしてVT340を使用している古いセキュリティシステムを持っていると想像してください。 現在、コロナウイルスのために、私は封鎖されて自宅で仕事をしているので、Windowsターミナルを使用してリモートでシステムにログインしています。 VT340と完全に一致する場合、これは問題ありません。端末は次のようになります。

しかし、多分私は奇妙なアスペクト比のフォントを好みます。 それでは、ほとんどの場合よりも幅が広い_MiriamFixed_でどのように見えるかを見てみましょう。 ボンドのイメージは少し押しつぶされたように見えますが、それでも彼は簡単に認識できます。

別の方法は、ピクセルパーフェクトな画像を使用することです（現在、conptyでは実行できませんが、少しふりをしてみましょう）。 ボンドは押しつぶされたようには見えなくなりましたが、画像は予想されたサイズのほんの一部になりました。 また、モニターの解像度が高いほど、見栄えが悪くなります。

これは個人的な好みの問題かもしれませんが、私は間違いなくオプション2よりもオプション1を選択することを知っています。

また、フォントのアスペクト比が1：2でない場合に、正確な動作を微調整するオプションがない理由がないことにも注意してください。 1つのオプションは、画像が占めると予想されるセル内の中央に画像を配置することです。 または、画像を拡大して領域全体をカバーすることもできますが、境界を超えたエッジをクリップします。 私の意見では、これらの選択肢はどれも、正確なピクセルレンダリングよりも優れています。

これは個人的な好みの問題かもしれませんが、私は間違いなくオプション2よりもオプション1を選択することを知っています。

私も、フォントのアスペクト比が異なることを知っている方がよいので、画像はそれ自体を調整して正しいものを維持できます。

1つのオプションは、画像が占めると予想されるセル内の中央に画像を配置することです。 または、画像を拡大して全領域をカバーすることもできますが、境界をオーバーフローするエッジをクリップします

それらを中央に配置する方が良いと思います。

たぶん私はこのスレッドを読み間違えています。 私たちは実際に、sixelイメージの10:20文字を偽造するターミナルについて話しているのですか？ それはボンドの歪みのような多くの問題を引き起こすと思います。 それを正しい方法で行うのはもっと難しいかもしれませんが、私の謙虚な意見では、現代の端末はフォントにとらわれず、アプリケーションプログラマーにシックスエルと文字セルの処理を任せるべきです。

エスケープシーケンスを使用して、ユーザーが実行するプログラムは、ピクセル単位の文字セルサイズを決定し、そのアプリケーションの歪みをインテリジェントに処理する方法を決定できます。 私が使用している画像表示プログラムは、まさにそのように機能します。 フォントファミリーまたはサイズを変更すると、表示されるサムネイルが常に正確に5テキスト行の高さに更新されます。 幅は、特定の（この場合はかなり大きい）最大値よりも大きくならない限り、画像に比例して拡大縮小されます。 画像サイズを文字セルに基づいて設定することにより、高DPI画面で自動的に機能します。

VT340はエミュレートする高貴な目標ですが、文字セルの解像度を10:20に修正する（したがって、画面全体の解像度を制限する）のは間違いです。 VT340はいくつかのsixel実装の1つにすぎなかったため、フォントサイズが必ずしも正確であるとは限りません。

10:20を強制すると、醜い応急修理にもつながります。 （たとえば、ターミナルウィンドウのサイズ（ピクセル単位）の要求に応答する方法。実際には、ウィンドウを画面上に配置すると想定しますか？または、ユーザーが6el出力の画像をスケーリングしていると想定して常に800x480を返しますか？ ）。

私たちは実際に、sixelイメージの10:20文字を偽造するターミナルについて話しているのですか？

はい。

最新の端末はフォントに依存しない必要があります

この提案はフォントに依存しません。 アプリケーションはフォントについて何も知る必要はありません。 それが要点です。

エスケープシーケンスを使用して、ユーザーが実行するプログラムは、ピクセル単位の文字セルサイズを決定し、そのアプリケーションの歪みをインテリジェントに処理する方法を決定できます。

使用している方法は正確にはわかりませんが、これまでに見た方法は、独自のXTermクエリを使用してウィンドウのピクセルサイズを取得し、別のクエリを使用してウィンドウのセルサイズを取得し、それを使用することです。実際のセルのピクセルサイズを計算するためのデータ。 このようなアプローチの欠点は次のとおりです。

1. これは独自仕様であるため、実際の端末、または実際の端末と完全に一致する端末エミュレーターでは機能しません。
2. アプリケーションの実行中にユーザーがフォントサイズを変更すると、計算が正しくなくなり、画像が間違ったサイズでレンダリングされます（実際的ではないように思われるフォントサイズを継続的に再計算している場合を除く）。
3. ユーザーが高解像度のディスプレイや大きなフォントサイズを使用している場合は、その解像度に合わせるために大量の画像を送信する必要があります。 Sixelがどれほど非効率的であるかを考えると、それは多くの帯域幅に相当する可能性があります。

とは言うものの、これは一部の人が使いたいと思うかもしれないモードであることを理解しており、少なくともいつかそれをサポートするオプションが必要だと思います（上記の理由により、現時点ではこれは不可能です）。 しかし、私の意見では、これはSixelにとって最善のアプローチではありません。

私は原子力発電所に300以上のVT340を持っていますが、最終的には
交換。

使用できる商用端末エミュレーションパッケージもありますが、
1つを除いてすべてがEoLされています。

それらの一部をXTerm（またはそれ以下）を実行しているLinuxPCに置き換えました
多くの場合、Win10 + Hummingbird + WSLはXTermを実行しています）、
中途半端なオープンソースのsixelの実装と、ある種の悪いですが
オープンソースのReGIS実装。

この部分のために新しいソフトウェアを作成する可能性
6オクテットストリームを生成するシステムはNILです。

インラインオクテットストリームを介してグラフィックを送信することが目的の場合は、
他のオプションです。 ただし、sixelグラフィックをサポートする場合は、
以前と中途半端な方法でsixelグラフィックをサポートする
実装。 これは、残念ながら、エミュレートする必要があることを意味します
模範的なシステム（つまり、VT240、VT241、VT330、およびVT340）の動作
グラフィックとテキストの統合に関しても。

これは私が話しているようなもののモックアップです。 とても
新しいSixelの実装が既存の実装との互換性を維持している場合は素晴らしい
画像が画面の端からはみ出さないように、または
画面の半分を埋めます。

https://vimeo.com/user32814426/review/467991744/ac5892fa7e

最新の端末はフォントに依存しない必要があります

この提案はフォントに依存しません。 アプリケーションはフォントについて何も知る必要はありません。 それが要点です。

つまり、すべてのフォントに10:20を課すのではなく、_terminal_をフォントに依存しないようにする必要があります。 アプリケーションは、必要に応じて実際のフォントサイズを認識できる必要があります。これは、表示しようとしているもののドメインを認識し、テキストとグラフィックスを一緒に表示するための最良の方法を見つけ出すことができるアプリケーションだからです。

エスケープシーケンスを使用して、ユーザーが実行するプログラムは、ピクセル単位の文字セルサイズを決定し、そのアプリケーションの歪みをインテリジェントに処理する方法を決定できます。

使用している方法は正確にはわかりませんが、これまでに見た方法は、独自のXTermクエリを使用してウィンドウのピクセルサイズを取得し、別のクエリを使用してウィンドウのセルサイズを取得し、それを使用することです。実際のセルのピクセルサイズを計算するためのデータ。

うん、そうだね。 文字のセルサイズを直接取得するクエリもありますが、画面サイズを取得してROWSとCOLUMNSで割るほど広くサポートされているとは思いません。

このようなアプローチの欠点は次のとおりです。

1. It's proprietary, so wouldn't work on a real terminal, or any terminal emulator that exactly matched a real terminal.

それはマイナス面ではありません。 これは、プログラムがとにかく実行することにフォールバックする必要があることを意味するだけです。$ TERM == "VT340"は文字セルが10:20を意味し、 "VT240"は10:10を意味し、 "mskermit"は8：8を意味すると仮定します。等々。

また、これはxterm独自のシーケンスではありません。 画面サイズの取得は「dtterm」エスケープシーケンスと呼ばれますが、実際にはSunViewで最初に実装されました（SunOS、1986）。 後でPHIGSプログラミングマニュアル（1992）に文書化されたと思います。 「\e[14t」をいくつかのターミナルエミュレータに送信してみてください。広く実装されていることがわかります。

2. If the user changes their font size while your application is running, then your calculations will no longer be correct, and images will be rendered at the wrong size (unless you're continuously recalculating the font size which seems impractical).

これは問題ではありません。 プログラムは単にSIGWINCHをトラップし、ウィンドウが実際に変更された場合にのみ再計算します。

3. If the user has a high resolution display, and/or large font size, you're forced to send through a massive image to try and match that resolution. Considering how inefficient Sixel is to start with, that can amount to a lot of bandwidth.

はい、sixelは非常に非効率的です。 しかし、最近のコンピューターでは、sshを使用していても、フルスクリーン画像を送信することは非常に便利です。 Microsoftターミナルにはある種のボーレート制限がありますか？

ちなみに、sixelには、すべてのドットの幅と高さが2倍になる「高DPI」モードがあると思います。 私はそれを使ったことがなく、xtermがそれを実装しているとは思わないが、おそらくそれは帯域幅に関する懸念を軽減するだろう。

とは言うものの、これは一部の人が使いたいと思うかもしれないモードであることを理解しており、少なくともいつかそれをサポートするオプションが必要だと思います（上記の理由により、現時点ではこれは不可能です）。

この「モード」は、さまざまな歴史的なシックスエル端末や現在のエミュレーターと同じように、文字とグラフィックスを揃えるだけです。 確かに、Microsoftターミナルで同じことができない理由がわかりません。 この10:20の恨みができる最高のことだと言うなら、私はあなたが正しいと信じて、それをしてくれてありがとう。 歪んだ画像は、何もないよりもはるかに優れています。

エスケープシーケンスを使用して、ユーザーが実行するプログラムは、ピクセル単位の文字セルサイズを決定し、そのアプリケーションの歪みをインテリジェントに処理する方法を決定できます。

@ hackerb9 、フォントのサイズを取得するための実際のエスケープシーケンスは何ですか？

関連するXTermシーケンスはここにあります： https ：//invisible-island.net/xterm/ctlseqs/ctlseqs.html-XTWINOPSを探します。

さらに、Unixでは、通常、TIOCGWINSZ ioctlを使用して、端末の内部ピクセルサイズとセルサイズを取得できます。 opensshを使用すると、これはリモートでも機能します。

データポイントと同様に、libvteのsixelブランチは、セルサイズに依存しないルート@hackerb9が話しているルートを使用しています。 着信するsixelデータを「ピクセルパーフェクト」として扱い、以前に受信した画像をズームレベルとフォントサイズにわたって再スケーリングして、一貫したセル範囲をカバーします。 マージすると、この実装は、GNOMEターミナル、XFCEターミナル、ターミネーターなどを含むLinuxターミナルエミュレーターの大部分で利用できるようになります。表面的には、これは少なくともXTermおよびmltermと相互運用できるようです。

libvteはイメージごとの仮想セルサイズを記録するため、相互運用のために固定の仮想10x20セルサイズでもこれを機能させるのは簡単です。 ただし、プログラムが予想されるピクセル：セルの比率を端末に伝達する方法が必要です（たとえば、DCSパラメーターを拡張することによって）。 これは、上記で触れたように、帯域幅に制約のある環境でのピクセル密度制御の形式も提供するため、一般的に非常に便利です。

さらに、Unixでは、通常、TIOCGWINSZ ioctlを使用して、端末の内部ピクセルサイズとセルサイズを取得できます。 opensshを使用すると、これはリモートでも機能します。

Linuxコンソールは常に0を返します...彼らはそれを修正する必要がありますが、あまりにも進んでいないようです：-/