OpenOffice.org 3.0 Writerのコピー＆カットに動作不良
テキストをドラッグする。
ドラッグ位置は色が反転する。
その範囲を右クリック・・・コピーまたは切り取り。
これが普通。
ところがどっこい、OpenOffice.org 3.0では、右クリックの際にドラッグ範囲がリセットされるバグがある。
確率としては半々～60％以上の確率だ。
これは頂けない。
非常にストレスが溜まるバグである。
早々に修正していただきたい。
2009年1月9日金曜日
2009年1月7日水曜日
OpenOffice.org 3.0 Writer テキストボックス内のコピペ不能
テキストボックスの中でテキストをコピーと切り取りはできるが、貼り付けが出来ないというバグを発見した。
尚、図形の中にテキストを貼り付けると、最上段のテキストのみが勝手にインデントされてしまう。
勿論、スケーらでアジャストしようとしたがスケーラが機能していないことから、これもバグであると認めざるを得ない。
2009年1月6日火曜日
OpenOffice.org 3.0 スペルチェックのON/OFF
ボタン１発でOFFにできるようにするにはどうすりゃいいんだ？
とりあえず、
ツール＞言語＞選択用
ツール＞言語＞段落用
ツール＞言語＞すべてのテキスト用
ここから３つとも「なし」にしたら黙り込んだ。
大体にして日本語辞書が無いクセに、文章のあちこちに赤い並線を引かれまくってクソ重いのなんのって。
こんなもんは、PDFにしてから読み直せば、修正箇所を自分でチェックできるから、最初のうちは基本的にOFFにしてくれるとありがたい。
それにしてもツールバーを固定にしても灰色になればすむのに、テキストボックスの文章を選択するとツールバーがいちいち消えて、画面がモッサモッサと縦に揺れるのは非常に頂けない。
「ツールバーの位置を固定」という機能がありながら、使い物にならないのであれば困る。
一番良く使うツールバーは例えそのときに使えなくても自動的に隠す必要は無いと思うんだよね。
何のための「ツールバーの位置を固定」なのか・・・
(*￣(エ)￣) 文句ばっか言ってるんじゃないんだよ。普通に使おうと思うと不便だってことだよ。
PDFに使う画像：Bitmapって実はJPEGやPNGより軽い
コンテンツに画像を埋め込む時、写真だとJPEG。キャプチャーならPNGやGIFと使い分けるのが定番の手法である。
そのほうがコンテンツの全体の容量が減って表示も軽くなるし、容量を抑えられる。
ただ、Office関連ソフトについては全く逆。
Microsoft Office / OpenOffice.org に限らず、これらのOffice Suite に埋め込む画像は、ファイルを保存する際に画像を可能な限り圧縮して保存する。
数MBのBitmap形式画像を埋め込んでも、文書ファイルの保存時の容量が数百KBになるのはそのためだ。
しかも画像が最初から圧縮されていないBitmapだからこそ余計な処理が掛からず、それらをPDFにエクスポートした時も、Bitmap画像は自動的に指定されたLZHかZip形式でPDF内部に格納される。
場合によっては文書ファイルよりもPDFの方が小さくなる事もある。これはそのソフトウェアがどのようなファイル圧縮を行なっているかによるのだが、勿論、MSとOOoで比較して同じ文書だとしても容量は異なるし、PDFに出力するソフトウェアによっても容量は変わる。
通常のPDF文書は300dpiや600dpiくらいで充分だが、実際の所、あまり極端に容量に差が出ない。
だから配布する時の容量が気になる人は、そのPDF文書の目的によってかなり高解像度な指定にしても良いし、そんなに解像度を必要としないものなら３００でも６００でもいいのだ。
もちろん、Bitmapともなると無圧縮の画像だけに、画像のサイズ＝容量となってしまう。だから圧縮するのにも限界があるわけで、Bitmapの色情報を減色することで圧縮した時に２倍程の差が出る。
通常は24ビットのフルカラーや、１６ビットで保存されるBitmapだけど、8ビットに綺麗に減色してくれるソフトウェアもある。しかも２手間（重複色の統合／未使用色の削除）まで行なうとパレットの最適化によって更に圧縮した時の容量が減る。
それでもBitmapには違いないので、より軽くなったBitmapはこれらのOfficeソフト上に貼り付けて使用した時にスクロールも滑らかだし、パラパラと時間を要して表示される事無く、サササッと表示される。
Mozilla Composerのマニュアルを作っていた昔にもこの件に関して記載したことがあるが、まだまだコツを掴んでいない人がいるのでたまには記事としてネットに情報をバラ撒くほうが良いだろう。
ちなみに２４ビットと８ビットのBitmapのサイズの違いは・・・
35個で 24bit=8.59MB / 8bit=2.91MB とサイズが３分の１まで減り、それらをZip圧縮すると
24bit = 274MB / 8bit = 166KB となる。４割も差が出る。
元々は 8.59MBの容量のものが256色に最適化されてPDF内に格納されると166KBにまで圧縮格納される。
つまり、 （8.59*1024）÷166＝だいたい50分の１ 程度にまで減ることになる。
これがJPEGやPNGにしてしまうと圧縮形式の画像を圧縮する事自体に効果が無いのでBitmapよりも容量が大きくなる。
文書を開いた時はちゃんと元画像のファイル形式は展開されているので文書上でもスクロールが軽い。
本当はPNGを更に不要なデータを削除するソフトもあって、フォトレタッチでPNG化して更に最適化を掛けるともっと小さくなる。
ただ、GIFやPNGを多用すると、多数のページがあるPDFを開いた時にスクロールがコマ送りになるくらいモッサリしてしまう上に、これ以上圧縮できないくらいに最適化されているのでBitmapの256色として保存した文書より巨大化してしまうことも多々ある。
ここで紹介しているComposerマニュアルVer4（最終版）も第４段を最後に極められる所まで極められた（2005年4月当時）訳だが、使用している画像は全てBitmapで、本来の文書のサイズなんてバラにすると軽く30MBにもなる。それも配布される時にやれるだけの最適化を施してあるので、６２ページフルカラーのマニュアルでさえも６．２MBで済んでいる。
もうひとつ。ウェブ上のコンテンツでは、サムネイルとしてのキャプチャーは全て実寸で使用して、必要に応じて文書内で縮小しよう。なぜなら、キャプチャーは殆ど色を使っていないのだが、画像そのものを使用する前に縮小してしまうと大量の中間色が発生して、元の画像で使われている色の数を大幅に上回ってしまう。でも、実寸の画像を文書内で縮小すれば、元の画像だから綺麗に表示される上に容量も下手に増やすことなく綺麗なままの画像を表示できる。
これはPDFビューワの画面上で縮小拡大してみると違いが出ることに気づくだろう。
これさえ守れば、画像タップリのPDF文書も配布時には思いっきり少ない容量になった版で配布できるのだ。
ただ、表示／印刷した時の美しさではSVG形式には絶対に勝てない。しかも線と塗りつぶしの情報で出来ているSVGはテキスト形式のデータの絵であるため、非常に圧縮にも優れている。
図解などでワードアートやオートシェイプ（OOoではフォントワークや図形描画という）をなるべく使うようにすると、同じ矢印のイメージでも、SVGではいくら拡大・縮小しようと画像の品質は変わらない。
反面、多用しすぎたり、一画面に大量のSVGを埋め込むと閲覧が重くなるのでやりすぎには注意が必要。
ウェブサイトでもPDFでも、使いどころによって最適な画像形式を最適なサイズとファイルタイプで加減するのは、見る側に与える印象も違う。勿論、ウェブサイトでは予め画像を縮小した方が良いし、使い分けで一番ファイル容量が小さい画像をその都度選択する必要はある。
マニュアルを作るのに何が大変か・・・って、そりゃキャプチャだよ
たとえば、ツールバーのキャプチャは見えているものには有効だけど、何かしないと色が着かない（要するに機能がONにならない）場合、ツールバーのカスタマイズの小さなメニューの中をスクロールさせながらキャプチャして切り取って、それらを整形しながら１枚の画像に繋ぎ合わせていくことだね。
しかもさ、表に出るツールバーと、機能を使用した時にのみ出現するツールもあるし、説明しようにも「なんじゃこりゃ？」なものがあるから、既に市販されているマニュアルとかも無い状態な場合は全部HELPに目を通さないと分らないし、見ても分らないって事がある。
自分で作ったソフトウェアや、使いこなせているソフトのマニュアルならまだしも、そのソフトウェアが多機能であればあるほど、マニュアルも巨大化するし、それらのキャプチャーの回数も増えるし、例えばそれらの画像が大容量になればなるほど画像を最適化しないとマニュアルそのものの容量も巨大化しちゃう。
かといって、最初からJPEGやPNGにしちゃうとスクロールがモタつくもんだから、無圧縮画像（つまりBMP＝ビットマップ）が一番表示が速くて見るものにストレスを与えない。
これを手抜きしてJPEGなんかにすると滲みが出るわ、汚いわ、サイズを可変した時のもっさり感がクソで最悪のものになる。Web上でやるのならキャプチャーはPNGやJPEGでも良いのだが、PDFにする時はSVGやBMPの２５６色モードが一番パフォーマンスが良いのだ。
で、キャプチャーだけど、ツールのカスタマイズの項目をチマチマやっているのだが、流石に手先が器用なオラでも、その膨大な量に具合が悪くなってきた・・・
ＯＳＳの世界では、やれる人が、やれることを、やれる時にやる・・・の精神だ。
つうことで・・・寝るわ （－（エ）－）．。ｏＯ ＺＺＺｚｚｚ
2009年1月5日月曜日
OpenOffice.org Writer テキストの文字色（メモ）
OpenOffice.orgが普及しない訳には根本的な操作性の非標準的な課題があると実感する。
Wordで言うところのテキストボックスの文字色に関しては、Wordはワードアートなどの画像としての文字を除くテキスト全てがツールバーから配色できる。
これは直感的で誰しも当たり前だと思える操作方法である。
ところがOpenOffice.orgについては、テキストボックスを挿入して入力した文字色を変えるためにプロパティーをわざわざ出さなければならない。しかも選択については以下のように非常に確実性が無い。
色を変えたい部分をドラッグして配色ができないなんてナンセンスだ。
①テキストボックスに相当するツールボタンをクリックする。
[T]のボタンをクリックして、範囲を選択するまでは同じだ。
②次に以下のメニューが出るまでテキストボックス内のテキストの範囲で右クリックする。
どうにかして出したら [ 文字(H) ] を選択する
③フォント効果でフォントの色を指定する。
テキストボックスの中のテキストの色を変えるだけにこれだけの手間が必要だ。
なんたる手間。なんたる面倒臭さ。なんたる不確定な呼び出し方。
普通、テキストボックスを選択して文字の色指定を行なうだけで済む機能も、クリックする位置がちょっとでもずれると、全く違うメニューが他に２種類ほど出る。
「いや、オラは文字の色を変えたいだけナンダヨ！」と思っても選択する場所によってツールバーが出たり消えたりで画面が上下に揺れる。クリックしたつもりがキャンセルされてしまったりでイライラする。
これはダメだ。これはもっとシンプルに、直感的に変えられるように簡略化（Wordと同じ操作）にするべきだ。これは面倒すぎる。
しかも、Wordの場合は選択したテキストボックスはそこに残るが、OpenOffice.orgの場合は、欄外にカーソルを置いただけで、選択範囲が消え去る。文字が入っていれば消えないが、いちいち文字を入れないと保持できないなんてナンセンスは使用者にストレスを与える。
これは頂けない。直してくれ。なるべく早く、分りやすく・・・
ちなみにオラは何度もOpenOffice.orgを直接入力するのが面倒なので、
OpenOffice.org ←おおお [変換]で出るようにした。
2009年1月3日土曜日
ロゴの模写：OpenOffice.org 3 Logo
まぁ、微妙に違うがロゴくらい用意してくれるとマニュアル作りやすいんだけどな・・・
マニュアル作る参考にHELPを見たけど。
(；´(Д)｀)＝３ 内容がしょぼぉ・・・
ってことで、本家のサイト
OpenOffice.org Ver2.x PDF（公開中です）PDF
OpenOffice.org Ver3.x PDF(製作中だそうです)
製本されたものは3000円くらいするわけだが、OpenOffice.org ３ の発表から書籍の出版まで随分と時間が掛かるじゃないですか・・・
2009年3月ってば、また、Ver3.2くらいになってそう。
その間に機能の追加とか互換性向上が図られるとマニュアルにも差異が出てきたりして。
こうなりゃ、基本的なワープロとしての Writer と、一般的な 表計算としての Calc と、最近は必須になってきた プレゼンテーション Impress の３つでいいから完璧なものを今月中に出した方がいいんじゃないかと。
あと、基本的な乗り換えガイド的なものを早々に・・・基本操作は似たようなものだけど、使う側にしてみれば、アノ機能はどこだー！！！ってのが一番のネックになってるというのに・・・
2009年1月2日金曜日
OpenOffice.org 3.0 Writer 検証中
その例の Book Mode に関して不具合を発見。
表示切替はタスクバーの右下には縮小拡大のルーラー（これも要望事項にはいっている）があって、そのすぐ左にあった。
１画面１ページ表示／１画面２ページ表示／１画面ブック表示 という風に並んでいるのだが、ブックモードだと１ページ目と２ページ目が並ばず、１ページ目がウィンドウ内の右上に、２ページ目がウィンドウ内下段の左側に表示されてしまうバグである。
一応、１画面２ページ表示で同等の事ができるものの、ちょっと詰めが甘かったようだね。
でもって、久しく利用していなかったのでどこに機能があるのか一通り探してみるが、一番最初にやるのが、ツールバーのカスタマイズと表示させるボタンの追加と削除。あとは使いやすいようにボタン群を並べ替えるだけ。
ただ、機能の呼び出しもそうだけど、どこに何があるのかちょっと分かりつらい。
そういう訳で慣れるまでにどんなカスタマイズが可能かキャプチャーなどを用意して、Writerの簡易マニュアルを作ってみようかと。
とりあえず、表示が命なので、各種パーツを編集中なのだが、上手くいくかどうかは分らない。
WriterでWriterの使い方をPDFマニュアルとして用意できれば幸いだ。
ただ、さっき手をつけたばかりなので出来上がりは未定だ。
ちょっとすると、4.0になってしまうかもしれないが、2.4から3.0へのバージョンアップはそれほど大きな変化は無かったので、部分修正すれば希望のものは手直しだけで定期リリースできるかもしれない。
何がしたいかって？ そりゃもう、決まってるでしょ。
WordからWriterに乗り換える時に、何処に何があるのか分かりやすくするためのマニュアルっすよ。
-----------------------------追記------------------------------------
（*￣（エ）￣） なるほどなるほど・・・こういうことか。
表紙はまず右側に。
２ページ目以降は見開きに表示される。
つまりこういうことか
通常（単） 並べて表示 ブックモード
納得した！
さて、続きをシコシコ作ろ・・・
OpenOffice.org 3.0 Writer Book mode
ああ、これ・・・オラがmixiのOOoコミュで要望した機能じゃん。(体裁として採用、機能はまだ発展の余地アリ)
ちゃんと要望が実現しとる！（一部だけど）
本当は、ページの綴じ代をBookモードの時に左右のページで可変するようにして欲しかったけど、これはこれで大きな進化だ。
これでマニュアル制作が本として印刷した時に実際の見た目を確認しつつ編集できるってもんだな。
登録:
投稿 (Atom)
投稿
