― MozillaZine.jp フォーラムは Mozilla 製品に関する情報交換の場です ―



All times are UTC + 9 hours

新しいトピックを投稿する トピックへ返信する  [ 11 件の記事 ] 
作成者 メッセージ
投稿記事Posted: 2011年10月09日(日) 04:07 
件名の事象が発生するのですが、対処はありますか?また、これは仕様なのでしょうか?


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2011年10月09日(日) 15:51 
オフライン

登録日時: 2008年5月26日(月) 01:41
記事: 1345
お住まい: 冥府
どの様な記述方法での再現に成るのでしょうか?

例としての抜粋でお願いします。

_________________

*Windows 10 21H1 64bit/*GoogleJapaneseInput:ATOK2017:MS-IME
Firefox 95.0:Beta 96:Developer Edition 96:Nightly 97.0a1:
Thunderbird 91.4.0:Earlybird 96:Daily 97.0a1:SeaMonkey 2.53.10/2.58a1:
Opera 82.0.4227.23:Google Chrome 96.0.4664.93/98.0.4756.0(Official Build)canary:
SRWare Iron 96.0.4900.0:Lunascape 6.15.2:Avant Ultimate 2020 build 3, 3.17.2020


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2011年10月10日(月) 01:06 
かなり説明が不足していました。
HPのHTMLテキストをcomposerを用いて編集し、一度保存したものを再度開いてみると、テキスト途中に何ヶ所が半角スペースが挿入されているのです。そこにカーソルを当てて削除しても、保存すると再び半角スペースが復活しています。(因みに、テキストは全角漢字英数カナのものです)実際にスペースが挿入されているので、該当のテキストをアップロードしてFirefoxでブラウズしても、その通りに空きが生じています。勿論、外見がやや気になるというだけの問題ではありますが…


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2011年10月10日(月) 01:11 
環境記述を失念しました。
WindowsXP下にて、SeaMonkey2.4.1(以前のバージョンでも同様でした)のcomposerです。


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2011年10月10日(月) 05:54 
オフライン

登録日時: 2008年5月26日(月) 01:41
記事: 1345
お住まい: 冥府
HTMLソースの事を指して云ってたのですが(汗
問題が再現される最小限のソースはどう云うのでしょうか?
個人情報やファイル参照関係は排除した上で。

_________________

*Windows 10 21H1 64bit/*GoogleJapaneseInput:ATOK2017:MS-IME
Firefox 95.0:Beta 96:Developer Edition 96:Nightly 97.0a1:
Thunderbird 91.4.0:Earlybird 96:Daily 97.0a1:SeaMonkey 2.53.10/2.58a1:
Opera 82.0.4227.23:Google Chrome 96.0.4664.93/98.0.4756.0(Official Build)canary:
SRWare Iron 96.0.4900.0:Lunascape 6.15.2:Avant Ultimate 2020 build 3, 3.17.2020


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2011年10月10日(月) 20:44 
横から失礼します。

少し婉曲な表現になってしまいますが、ご質問の現象は SeaMonkey の "バグ的な仕様"(*)によると思います。
この問題は以前から存在し、現在の SeaMonkey 2.4.1 でも変わっていません。

【背景】
(1)一般に HTML 文書では、コンテンツの文字列に改行コードが含まれるとき、ブラウザではこれをスペース(半角スペース)として表示します(仕様)。SeaMonkey の Composer 画面でも、HTML ソースを表示するという点では同様です。
(2)SeaMonkey の Composer は、連続した長いコンテンツの文字列に対し、自動的に改行コードを挿入する仕様になっています。

【欧文の場合】
単語ごとにスペースで区切られた文章構成になります。
(例)
~ SeaMonkey all-in-one internet application suite. ~

この文字列に Composer が自動的に改行コードを挟み込む場合、必ずスペース部に改行が入ります。
(例)
~ SeaMonkey all-in-one internet[改行コード]
application suite. ~

これを、Composer で再度開いたり、ブラウザで表示したりすると、改行コード部分がスペースで表示されますが、表示上は元の通りです。
(例)
~ SeaMonkey all-in-one internet application suite. ~

【日本語文の場合】
原則として文章中にスペースを常用することはありません。
(例)
~ SeaMonkey は、すべてが一体になったインターネット用のソフトウェアパッケージです。 ~

このとき、Composer が自動的に改行を挟む場所は、文中にスペースがないため単純に既定の文字数(またはバイト数)に依存し、日本語として意味を持った単語の途中に改行コードが機械的に挿入されます。
(例)
~ SeaMonkey は、すべてが一体になったインターネット用のソ[改行コード]
フトウェアパッケージです。 ~

これを、Composer で再度開いたり、ブラウザで表示したりすると、改行コード部分がスペースで表示されるため
(例)
~ SeaMonkey は、すべてが一体になったインターネット用のソ フトウェアパッケージです。 ~
―― のように「ソ」と「フ」の間に半角アキができます。

【考察】
以上のような動作は、欧文では何の問題もない仕様といえますが、日本語のような文章表記をする言語では、不自然な箇所にスペースが入ったように表示されるケースが起こりえます。
つまり、使用言語によってはバグになりうる仕様という意味で、"バグ的な仕様"(*)というわけです。
  | 表示上の不自然さ以外に問題が発生するわけでありませんが、
  | 厳密な幅を規定したボックスに配した文字列に半角スペースが
  | 入ることで、まれにレイアウトに影響を与えることもあります。
  | もっとも、その程度で影響を受けるデザインのほうに問題がある
  | という言い方もできるわけですが......。

全角のみの日本語文字しかない場合と日欧(全角・半角)混在の場合では改行が入る場所に違いがでますが、一定以上の文字列に改行が挿入されるという SeaMonkey の動作に違いはありません。

【結論】
現状の SeaMonkey を使う限り、隠し設定を含めた設定変更等での回避策は見出せません。
テキストエディタを併用するなどして、ユーザーが意識的に調整するしかないと思います。

(補足)
コンテンツ文字列の自動改行に限っていえば、KompoZer のほうが問題はないのですが、8.0b3 以降長期にわたって開発が止まっていますし、SeaMonkey にはない別の問題もありえるため、一長一短といった印象です。

解決策ではありませんが以上です。外してたらすみません。

(余談)
SeaMonkey のブラウザ部やメールクライアント部の進化は、Firefox や Thunderbird に即している傾向がありますが、Composer 部は遅々とした変化しかありません。つまりは、それだけユーザーのニーズが少ないからだと考えられるわけですが...。
コストをかけずワープロ感覚で手軽に HTML 文書を作成できる点では、SeaMonkey の Composer を使う利点はおおいにありますが、規格に厳密な HTML 文書が必要とか、ビジネスとして本格的なサイトを作るといった用途には不向きです。
Dreamweaver などの高性能だが高価なソフトウェアや、安価だが規格はずれのソースを吐く有償ソフトウェアを使わない前提でいうと、SeaMonkey や KompoZer でざっくりページの骨格を作り、あとはテキストエディタで細部を仕上げていく方法が一番安心できると、個人的には思っています。


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2011年10月10日(月) 22:05 
了解です、大いに納得しました。
やはり仕様的な問題だったのですね、つまり[自動挿入 オン|オフ]というスイッチを設けてもらわない限り解決しない訳ですか…自分にその力量があれば対策したいところですが、今現在の自分にはちと手の届かない領域にあるようです。
貴重なご指摘、誠に有難うございました。


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2011年10月10日(月) 23:48 
オフライン

登録日時: 2008年5月26日(月) 01:41
記事: 1345
お住まい: 冥府
言語上バグ仕様以外を疑ったのですが、質問者の事案は私の杞憂に終わった様子です。
何れにしても此のバグは困ったモノですね。

_________________

*Windows 10 21H1 64bit/*GoogleJapaneseInput:ATOK2017:MS-IME
Firefox 95.0:Beta 96:Developer Edition 96:Nightly 97.0a1:
Thunderbird 91.4.0:Earlybird 96:Daily 97.0a1:SeaMonkey 2.53.10/2.58a1:
Opera 82.0.4227.23:Google Chrome 96.0.4664.93/98.0.4756.0(Official Build)canary:
SRWare Iron 96.0.4900.0:Lunascape 6.15.2:Avant Ultimate 2020 build 3, 3.17.2020


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2013年6月08日(土) 02:42 
…上記のようなアラートを挙げた以上、どなたか対処して下さるのではないか…と待って1年半経ちました(笑)

「どなたか対処して下さい」という正式なリクエストは、どうやって上げれば良いですか?

_________________
Mozilla/5.0 (Windows NT 5.1; rv:21.0) Gecko/20100101 Firefox/21.0


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2013年6月24日(月) 17:08 
元々は、HTMLの改行の仕様が日本語などのテキストの書き方とは相容れない「空白一文字」で、その上に、HTMLでは厳密には仕様を定めていなくて、空白が単語の分離記号の言語もあるし空白を使わない言語もあるからよきに計らえ、ってな感じのものだから、どうしようもない...

text/plainのformat=flowedでは、この「挿入された空白」問題はどうあがいても対処のしようがなく、RFCでformat=flowed,DelSp=Yes(default=No)を新規に定義し、各メーラーで、表示の際のformat=flowed,DelSp=Yesをサポートし(Thuderbirdを含めメジャーなメーラーの多くが既にサポート)、メールの作成の際に、format=flowed,DelSp=Yesで作成(まだ一部のメーラーのみ、Thunderbirdは、まだ大多数のメーラーがformat=flowed,DelSp=Yesをサポートしているわけではないので、format=flowed,DelSp=Yesを使用していない)、というようになっています。

text/htmlメールは、元々がformat=flowedみたいなものだから、format=flowed,DelSp=Yesをtext/htmlにも拡大解釈し(Content-Type: text/html; format=flowed,DelSP=Yesは、RFC Violationとは言い切れないはず)、HTML⇒テキストコンバージョンでも、DelSp=Yesならば改行のあとのスペースを除去、というようにすれば、対処は可能です。
他の大多数のメーラーと歩調を合わせないと、無意味ですけど。

なお、ユーザーが意図的に改行なしの極端に長いテキストをメールの作成画面にペーストした時に起こる様々な問題の多くは、 https://bugzilla.mozilla.org/show_bug.cgi?id=653342 の中で触れられ、関連する多くのバグがポイントされています。
HTMLソースの整形のため、あるいは、Tbの内部的なHTMLの一行の長さ制限(80文字弱)のために、HTMLタグの中の属性値の間に改行を入れてしまう、という、HTMLメーラーとしてあるまじき悪行も含まれています。
Bug 653342 は、問題を引き起こす「HTMLメールの中での改行の挿入」を止め、メールの行長制限に引っかかる場合にはBase64で送る、というものです。
テキストモードのメール作成における「改行の挿入」に関連する問題は、このバグの守備範囲外です。

_________________
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2013年6月27日(木) 08:20 
通りすがり さんから、技術的に詳しいご説明をいただいていますが、過去にこのトピックに首を突っ込んでいた関係上、いくつかコメントさせていただきます。

りゃあ さんが書きました:
…上記のようなアラートを挙げた以上、どなたか対処して下さるのではないか…と待って1年半経ちました(笑)

ご存知だとは思いますが、「フォーラムの利用について」にも書いてあるように、このフォーラムの性格はユーザー・コミュニティが本領であり、不具合報告の場ではありません。
なので、ここで不具合を話題にしたからといって、自動的に開発に反映されるものではありません。
http://forums.mozillazine.jp/faq.php?mode=forum

りゃあ さんが書きました:
「どなたか対処して下さい」という正式なリクエストは、どうやって上げれば良いですか?

基本的には、Bugzilla にバグ報告を上げて、そこでの議論を経て、実際の修正作業へと動くようです。
「どなたか対処して下さい」が、プログラムのソースコードの修正を意味しているのなら、きちんとしたバグ報告を上げないと開発陣には何も届かず、改善は期待できません。
(参考)・Bug writing guidelines | MDN
https://developer.mozilla.org/ja/docs/Bug_writing_guidelines

バグ報告を上げること自体を「どなたか対処して下さい」とおっしゃっているのなら、普通はそういうチャンネルはありません。
せいぜい、同じニーズを持った他のユーザーさんが報告を上げるのを、期待して待つぐらいでしょうか。(Bugzilla を詳しく調べると、すでに報告が上がっているかもしれませんけど...。)

とりあえず以上です。的外れな話だったらすみません。

(余談)
ご存知かもしれませんが、本件に関連して BlueGriffon が独自の対応策を採り入れています。
 [長い行を折り返す] - 有効/無効
 [折り返しの基準桁(文字数)] - 数値指定
 [次の言語には折り返しを適用しない] - 言語の指定(ja, zh-TW, zh-CN, ko など)
―― といった設定項目があり、作成する HTML 文書における自動改行の動作を、(限界はあるがそれなりに)コントロールできます。
とくに [次の言語には折り返しを適用しない] は、東アジア言語のためにあるといっても過言ではないぐらい、日本語記述での自動改行の動作に関して重宝すると思います。
(それでも、改行のない極端に長い文字列を扱う場合は、作成者がそのことに注意を払う必要があることにかわりはないと思いますが...。)

ただ、独立した HTML エディタだからこそできるという側面があり、同じことを SeaMonkey に採り入れるとしたら、メールクライアント部分との整合性を考える必要があるかもしれない分、難しい要素が多いかもしれません。(たぶん HTML 編集のエンジン部分は、Composer とメールクライアントで共通だったと思うので......。違ったかな??)

【おことわり】
ゲスト(未登録)ユーザーで投稿しようとした場合、本文にフル URL や [url] タグで設定されたリンクがあるとスパム判定されるケースがあり、今回もその制約に引っかかって投稿できません。
仕方ないので、「URL を自動的にパースしない」の設定で投稿しています。ご容赦ください。

_________________
Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20100101 Firefox/22.0


通報する
ページトップ
  
引用付きで返信する  
期間内表示:  ソート  
新しいトピックを投稿する トピックへ返信する  [ 11 件の記事 ] 

All times are UTC + 9 hours


オンラインデータ

このフォーラムを閲覧中のユーザー: なし & ゲスト[0人]


トピック投稿:  可
返信投稿:  可
記事編集: 不可
記事削除: 不可
ファイル添付: 不可

検索:
ページ移動:  
Powered by MozillaZine.jp® Forum Software © phpBB Group , Almsamim WYSIWYG
Japanese translation principally by ocean