ごまめの遠足。

個人的なお気に入りの場所・ツボにはまった場所を紹介

  • 過去のひみつ基地
  • GPSのデータについて
  • 旧・バーチャロン関連は工事中

計算機とか

L判写真をマット印刷する大作戦!!

最近体調が優れないことについて気づいたことがある。もしかして運動強度がない間に、身体が人並みに弱くなったのではないか? ということ^^; となれば、しばらくは意識してバイクで出歩くべきであろう。

ということで、床屋にバイクで出かける。他のバイクに置いていかれる(汗)。やっぱり練習しよ。

続いて、L判写真用のマット紙を探す。というのも『フォトマット紙/顔料専用』って、A4に印刷するぶんには特に気にならないくせに、L判に裁断すると、かなり薄く感じられるから。L判ということで、無意識に印画紙と較べてしまうのかもしれない。

といっても、件の紙は厚さ0.26mmで、私が持っている純正光沢紙では絹目0.27mmとほとんど違わず、にもかかわらず絹目には(物理的な)違和感を感じたことはない。『写真用紙エントリー』に至っては、持ち合わせがないから比較はできんけど、全く同じ紙厚らしい。あるいは光沢紙って、紙厚の割に「硬い」のだろうか?

そんなわけで、紙厚0.26~0.30mmのマット紙を探す、が、ほとんど無えや(汗)。つくづくマットで写真を印刷する酔狂ぶり、あるいは先覚者ぶり(笑)を思い知る。ファインアートならあるが、A3ノビのファインアートでL判を印刷したことのある人は、シャレとしてもおそらく誰もいないに違いない。

結局、ハーネミューレのフォトラグ300ミクロンのはがきサイズ(角丸缶入り)が、限定販売と称して売られていたのを購入。ファインアート系以外で条件を満たしていたのは、サンワサプライの『2番目に厚い両面つやなし用紙』の0.28mmしか見当たらなかった。が『スーパーファイン相当』。まあお手並み拝見ということで併せて購入。

そしてテスト印刷だが、予想を超えた事態がいくつか発生した。

さすがハーネミューレだけあって、たいていのプリンタに対応したICCプロファイルが用意されているのはいいとして、それと一緒に『設定方法』のPDFもZIPされている。それ見たら「メディア指定はVelvetにしろ」だって。Velvetを指定してくるかと感心したのもつかの間、給紙方法が『リア手差し』に強制切換した。

先日言及したとおり、リア手差しにはA4未満の用紙はセットできない。通常版だったら問題なかったのに、いちびってハガキサイズを買った(さらに言えば、作った)おかげで招いた事態である。

とにかくオートシートフィーダから給紙させる(紙厚的には問題ない)ために、メディア指定を元に戻す。というかそれに加えて『超高精細』で印刷するなら『フォトマット紙』しか選択肢がない。まあ色変換はPSE側でやっているので、ドライバのメディア指定は影響がない…と思いたい。

で、カラープロファイルをセットして印刷したら、最終局面で斜行発生(汗)。1枚パーになったことよりも、これまで徹底的にフチなし印刷を避けてきたのに、初めてプリンタ内部に印刷してしまったことに対してショック。「角が丸い」のとの関連は不明。とはいえ、後端までフチなし印刷できるはず(試してない)のプリンタが、異常な用紙とはいえ15mmも手前から印刷不能に陥るというのは考えにくい。今のところ、反った硬い用紙のため、ローラーが掴めず空回りした説が有力。ってことは、やっぱりA4だったら大丈夫だったのかもしれない。

いずれにしても、後端がまた乱れたらイヤなので、画像を極力頭端に寄せて対処。幸いに、L判でカットする使い方なら、長辺方向はかなり余裕がある。

印刷成功する限りは、まあマットとしては上出来かな。ただプラテンギャップは『広め』にしておいた方がいいかもしれない。

実は、最初の印刷でヘッドが紙面をこすったっぽいので、用紙の反り方向を変えるために裏返しで給紙したところ、普通紙よりもひどい結果が出た。ここでまず思ったことは「ヘッドクリーニングするか」であって、フォトラグにも裏表があることに気づくのにはちょっと時間がかかった。こないだ学習したはずなのにねえ。ちなみに、どっちが表か判らなくなったら、触ってみて滑らかなほうが印刷面である。

今回のケースでは、むしろ技術屋としての教訓を得た。ある条件でテストを通した場合、その派生品を出すにあたって条件のことを忘れて結果だけを根拠にして、派生品に対するテストを軽視してしまうことがままある。むしろオリジナル品でテストを徹底的にやった自負があるほど、この落とし穴にはハマりやすいのではないだろうか?

で、サンワサプライの方だが『超高精細』でも、わりと見られる結果になった。フォトラグの方が多少青味が強いかという程度。ただインクの多い部分がフォトラグに較べてつぶれるところが『スーパーファイン』レベルかもしれない。今回は雪景色でテストしたので、たとえば夜景などでは『高精細』に落とさないと見られなくなる可能性はある。

さすがにICCの提供はないので『Matte Paper Pigment』と『Super Fine Paper』の両方を試したところ、見比べてスーパーファインの方が多少黄色が濃いめに出るのがわかる程度で、どちらか1枚だけ見ても、私の目ではあまり不自然は感じない。よく見たら、スーパーファインの方が、その黄色の部分を濃くするためのインク滴が比較的目立つか。

なお『超高精細』を選ぶには、やっぱりメディアは『フォトマット紙』を選ぶ必要があることは言うまでもない。

そして驚くべきことに、サンワサプライの0.28mmの方が、フォトラグ300ミクロンよりも硬い。いやコットンだから柔らかいという話ですらなく、持った感じからして明らかにフォトラグは薄い。

怪しいと思って調べたら、秤量ベースではフォトラグは188g/sqmで『フォトマット紙/顔料専用』の189g/sqmとほとんど変わらないことが判明。そもそもフォトマット紙よりもしっかりした紙を探しているのであるから、コレではほとんど意味がない。紙厚については、責任ある第三者機関で、共通の測定方法で測ってもらう方が絶対いいと思う。

ということで、フォトラグは「写真用マット紙の代替」ではなく、あくまでも適度にテクスチャのついた「インクジェット用ファインアート紙」として活用することになりそうだが…となるとハガキ大は使い勝手がいまいちかも(汗)。

他方、そのフォトマット紙/顔料専用についても怪しいところがある。パッケージには0.26mmとあって、私もそう思い込んでいたのに対して、それ以外の情報源では、店頭のカタログも、Webの製品情報でも0.25mmになっている。なるほど0.25mmなら、絹目よりも薄く感じられても不思議ではない、かもしれない。

…って納得しとる場合ではない。どっちが本当なの!? どっちも正しいとすれば「ユーザが実戦で使う頃には、湿気を吸って0.26mmに膨れるところまで計算した」と推測せざるを得ない。パーシモンのドライバーとちゃうゆうねん(笑)。

あるいは、パッケージングされた時点で1枚単位の測定を諦めたとしたら!?? 全体の厚さを測って50で割るであろうから、そこに空気あるいはクリーニング用紙の厚さも紛れ込めば、2枚分ぐらい余分に分厚く測れるのは納得できる話である(オイ)。

2011/02/27 12:13 | カテゴリー:計算機とか | コメント(0)

長尺印刷 v. PX-5600 さらにヒッパる

給紙指定に『ロール紙』と『ロール紙(長尺)』があるけど、これってどう違うのか!?

マニュアルの文句と、印刷設定での挙動からまとめると

  • 『ロール紙(長尺)』は、長尺対応アプリから印刷する時に現れるらしい
  • 長尺対応アプリでは、用紙サイズを超えた印刷ができるらしい
  • 『ロール紙(長尺)』を選ぶと、切取線の印刷指定のチェックボックスが用紙節約のチェックボックスに変わる

…もしかして、印刷設定で言う『長尺』って「原稿ごとに用紙排出しない」、いわば昔のラインプリンタに似た動作モードという意味なのかな? たとえばA4サイズの1文字、という印刷を10回繰り返すと、普通なら印刷単位ごとにフォームフィードがかかるべきところ、前のデータにすぐ続いて次のデータを印刷することで、あたかも10文字からなる巨大なデータを印刷したような結果になる。

これなら、1文書あたりの用紙サイズはそれほど大きくなくても、比較的簡単かつ確実に(途中で予期せず白紙になったりせずに)印刷できそうだ。「サポート用紙サイズ以上の大きさの印刷ができる」というのも、この仮説に従えば辻褄が合う。

そんな中で、事もあろうにメーカーサイトで「いくつかの長尺対応アプリで長尺印刷するノウハウ」みたいなページが公開されているのが気になっている。何が気になるって、いずれも長尺印刷と言いながら『ロール紙(長尺)』を選んでいないのだ。すなわちここで言う『長尺』とは、文字どおり単なる『長い紙』という意味であって、そのテーマは、あくまでも「長い単票用紙に一発で印刷する」なのだ。

PX-5600がサポートする最大長3276.8mmは、プライベートレベルでは充分長いのかもしれないが、不定形用紙としてセットした範囲内で編集・印刷する以上、所詮「ちょっと長い単票用紙」に過ぎない。「単票用紙の印刷にロール紙を使いました」であれば、これは『ロール紙(長尺)』ではなく『ロール紙』設定になるべきであろう。

とりあえず、印刷設定で『ロール紙(長尺)』が出るということは、Office2007シリーズもIllustratorCS4もPSE9も長尺対応ということらしいが、いずれも印刷設定で定義した用紙サイズはプレビューで超せたことがない。すくなくとも超える方法は見つけられていない。実は印刷してみたら何事もなく出る??のかもしれんけど、これはさすがにどこかから調査費でも出ない限り確認する気がおこらない(笑)。

まあ印刷できれば用語のブレなんかはどうでもいいけど、各印刷単位の長さ(=隣同士のデータの位置関係)をいちいち計算しなくてすむ有利も捨てがたいので、仮説どおりに長尺印刷できるかどうか確かめてから、こっちの方も調査してみたいものである。後継機種が出たというのに何をやっているのか!? んで後継機種では、このへん色々考えているのが無意味なぐらいスッキリ解決していたりしてね(笑)←あくまで未確認です

…もし「長尺対応アプリでは『アプリが扱えるサイズの原稿』を超えたサイズの印刷ができる」の誤記だったら、上記ノウハウサイトの件も含めてすべての辻褄は合うけど^^;

2011/02/25 22:28 | カテゴリー:計算機とか | コメント(0)

長尺印刷 v. PX-5600 延長戦

先日の印刷失敗について、不覚にもドライバの印刷設定の『プレビュー』を忘れていた。考えたら、プリンタに送るそのままのデータを画面に出すのだから、アプリケーションの『プレビュー』よりは断然アテになる。

実際、先日のバナーを同じ条件でプレビューかけてみると、果たして同じ場所から白紙になる画像が出てきた。これを使えば、実際に紙を消費しない分、調査が断然楽になるのだ。ただし、用がなくてもプリンタの電源を入れないとプレビューできないのが難点。いやオフラインで動かせないわけがないから、こんな制限は比較的簡単に無くせるでしょ!? 知的財産がらみとか、オトナの事情があるんかもしれんけど。

さて今回は、今さらながら、PX-5600のロール紙ホルダーについて詳しく。

ホルダーのうち右側は実質的に右端固定だろうから、左側がセットできる5箇所について、右端との間隔を調べてみた。

他方、ロール紙ホルダーが保持できるのは、その構造から溝の場所から内側5mm、外側16mm程度までと考えられる。ただし右側のホルダーについては右端、すなわち外側につける必要があるはずなので、結局保持できるロール紙の幅は、溝同士の幅+11mm~+16mmという計算になる。

5組の溝同士についてスパンを実測し、そこからセットできそうな最小・最大幅を計算したのが下表。ただし50cm定規での実測につき、1~2mm程度の誤差は確実にあることをご了承いただきたい。

単位:[mm] 溝間 MIN MAX セット可能用紙(推定含む)
#1 58 69 90 L判(89mm)
#2 70 81 102 はがき(100mm) KG(102mm)
#3 98 109 130 2L(127mm)
#4 180 191 212 六切(203.2mm) A4(210mm) レター(215.9mm)??
#5 298 309 330 A3ノビ(329mm)

さて、マニュアル上では、203.2mm(六切?)、210mm(A4)、215.9mm(レター?)、297mm(A3)、304.8mm(四切?)、329mm(A3ノビ)の6種類のみ『フチなし印刷』が可能とある。

しかし、上記のうち297mmと304.8mmは、どう考えてもロール紙ホルダを本体背面に装着して給紙できるとは思えない。逆に、少なくともドライバの印刷設定では、ユーザ定義サイズでどのような数字にしても、フチなし印刷のチェックは無効にならないし、ポップアップもフチなし印刷可能と言ってくる。もっとも、今のプリンタでフチなし印刷は、よっぽどのことがない限り避けるつもりでいるけど。

それにしても、先日も似たようなことを書いたが、六切のロール紙とかなんか、見たことないけどなぁ。

2011/02/24 22:35 | カテゴリー:計算機とか | コメント(0)

証明書更新

POP3sとIMAPsとFTP o. TLSの証明書が期限切れにつき更新。

更新自体は昨年まとめたとおりで、10分かからずに完了するが、有効日数が366日ということで、切れたのに気づいて更新すると、1年で1日ずつずれていく。

よく考えたら昨年も今年もたまたまオフの日だったので早めに気づいたが、来年もそうとは限らない。当然ながら、こういうのは前年と同日、すなわち期限が切れる1日前に更新するべきであろう。

となると、毎年この時期だと今回と同じように忘れているので、やっぱり正月近辺に更新するべきかもしれない。

2011/02/13 23:41 | カテゴリー:Fedora, 計算機とか | コメント(0)

Windowsサーバのsendmail.exe

職場のWebサーバで運用しているFSWikiの参照の一部が、FirefoxでクリックしたらInternalServerErrorになるという昨日の一件。

参照の一部だけ、さらにFirefoxだけで発生するというのが怪しいが、このサーバってば、リモートでGUIができるという理由でWindowsを走らせているくせに、Web関連ではApache for Win32とか、1行目のパス指定が#!/usr/bin/perlになっているperlスクリプトとか、まあUnixyなコードが入っている。おかげで何かあった時の心当たりが広すぎるのが困りものである。

個人的にはむしろリモートコンソール(SSH)の方が好きなのだが、私の次が引き継いだ時に困るとおっしゃる。トラブルの原因の特定に手間がかかるとか、それ以前にわざわざトラブルが発生しやすい状況を作るのを思えば、いくらGUIでわかりやすくても意味がないと思うけどねえ。

それはともかく、apacheのエラーログ見たら、ヘッダの内容がおかしいと出た。Bad header= =?ISO-2022-JP?B?Zg==?="だと。どういう事情かはよくわからないが、ファイル名を渡す処理のどこかでMIME64に変換しようとして失敗しているらしい。試しにWikiについてきたJcode.pmの該当箇所で、変換を通さずに(EUC-JPの)ファイル名をそのまま返すように細工したら直った。

本来なら、なぜFirefoxの時だけここを通って失敗するのかを調べなければならないところだが、サイト内部でメールを出したりしない限り、MIME64への変換は行われない、とみなして(本当かどうかは知らん)しばらく様子を見る。あとFSWikiは他のホストでも使われているが、それぞれのlibディレクトリの下のJcode.pmを使うはずなので、この意味でも問題ないだろう。というか他のFSWikiはどうして平気なのか!? ひと世代旧いから?

と思ったら、翌日Webサーバからメールが来ない。サードパーティのsendmail.exeでエラーログを私宛に出すスケジュール、ただしエラーログの出ない日はメールを出さない仕掛けにはしているが、昨日あれだけトラブったのでさすがに気付いて、リモートデスクトップを開いたところ、おなじみ「ご迷惑をおかけして申し訳ありません」のダイアログが出てsendmail.exeが停まっている。メールだけにMIME64関連をいじったのを疑ったが、一時的に元に戻しても改善なし。よく考えたら、C:\Perl\binに間借りしているsendmail.exeが、一介の!?ホストのJcode.pmなんか見に行くはずがねえや。

ということで、昨日やったことを思い出しながらテストしたところ、どうやら環境変数PERLLIBにパスをセットしたのが直接の原因らしい。真の原因はよくわからんが、とにかく削除したら回復した。パス自体は間違いなかったはずだが、パス区切りに"/"を使ったのがまずかったのか、あるいはそもそもWindowsではセットしたらいかんかったのかはよくわからない。まあ結果的には、昨日のエラーの心当たりがありすぎて色々無用無益な手を打ったせいということになる。Windows自体が悪いとは言わんが、Unixyなツールが絡むと、恐ろしくメンテナンスコストのかかるサーバになりうるのだ。

2011/01/29 00:32 | カテゴリー:Windows, 計算機とか | コメント(0)

« 古い記事 新しい記事 »

  • 過去記事検索

  • カテゴリー

    • 写真
    • おさんぽ
    • 自転車
    • ハイキング
    • 計算機とか
    • Fedora
    • Windows
    • ビデオ録画とか
    • ゲーム
    • FS2004
    • FSX
    • ただの日記
  • 最近の投稿

    • 北湖一周とパター3本目
    • 猛省
    • サーバ入れ替え
    • 準カレー事件
    • 洗濯機排水ホース交換 ×2
    • BR-6500(F)
    • 白猪ノ氷瀑
    • 『ウォーキングマシン』HSM-T08D のこと
  • アーカイブ

    • 2014年10月
    • 2013年10月
    • 2013年9月
    • 2013年8月
    • 2013年2月
    • 2013年1月
    • 2012年12月
    • 2012年11月
    • 2012年10月
    • 2012年5月
    • 2012年3月
    • 2012年1月
    • 2011年12月
    • 2011年11月
    • 2011年10月
    • 2011年9月
    • 2011年8月
    • 2011年7月
    • 2011年6月
    • 2011年5月
    • 2011年4月
    • 2011年3月
    • 2011年2月
    • 2011年1月
    • 2010年12月
    • 2010年11月
    • 2010年10月
    • 2010年9月
    • 2010年8月
    • 2010年7月
    • 2010年6月
    • 2010年5月
    • 2010年4月
  • 2025年7月
    日 月 火 水 木 金 土
     12345
    6789101112
    13141516171819
    20212223242526
    2728293031  
    « 10月    

* RSS FEED

※過去の記事は順次統合中です

Copyright © Master Keystone, 2001-2011