"UI部品の各種別に対し、操作者の編集権限が設定された権限情報を記憶する第1記憶手段と、前記種別に対する編集の優先度を表す優先情報を記憶する第2記憶手段と、編集画面を表示制御し、操作画面内の各UI部品の編集指示を受け付ける操作手段と、前記操作手段が編集指示を受け付けた第1UI部品の種別に対応する権限を、前記権限情報に基づき判断する第1判断手段と、編集後の前記第1UI部品と他の第2UI部品とが重なる場合、前記優先情報から取得した前記第1UI部品の種別に対応する優先度と前記第2UI部品の種別に対応する優先度とに基づき、前記第1UI部品の編集が可能か否かを判断する第2判断手段と、前記第1及び第2判断手段の判断結果に基づき、前記第1UI部品の編集を制御する編集制御手段と、を備える画像形成装置。前記第1判断手段は、前記第1UI部品と関連付けられている他の第3UI部品がある場合、前記第1又は第3UI部品の権限のいずれかが権限ありを示すとき、前記第1及び第3UI部品の編集を可能とする請求項1記載の画像形成装置。前記権限情報の権限の編集、操作者の権限の追加を行う権限編集手段をさらに備える請求項1又は2記載の画像形成装置。前記優先情報の優先度の編集、新規種別の優先度の追加を行う優先度編集手段をさらに備える請求項1乃至3いずれか一項に記載の画像形成装置。前記第1判断手段により権限なしと判断された場合、又は第2判断手段により編集不可と判断された場合、編集が不可を示すエラー通知を行う通知手段をさらに備える請求項1乃至4いずれか一項に記載の画像形成装置。前記通知手段は、前記編集指示を行った操作者の権限に基づき、編集可能な編集内容を前記エラー通知とともに通知する請求項5記載の画像形成装置。画像形成装置に実行される編集方法であって、編集画面を表示制御し、操作画面内の各UI部品の編集指示を受け付ける操作ステップと、UI部品の各種別に対し、操作者の権限が設定された権限情報に基づき、前記編集指示がなされた第1UI部品の種別に対応する権限を判断する第1判断ステップと、編集後の前記第1UI部品と他の第2UI部品とが重なる場合、前記種別に対する編集の優先度を表す優先情報から取得した前記第1UI部品の種別に対応する優先度と前記第2UI部品の種別に対応する優先度とに基づき、前記第1UI部品の編集が可能か否かを判断する第2判断ステップと、前記第1及び第2判断ステップの判断結果に基づき、前記第1UI部品の編集を制御する編集制御ステップと、を有する編集方法。編集画面を表示制御し、操作画面内の各UI部品の編集指示を受け付ける操作ステップと、UI部品の各種別に対し、操作者の権限が設定された権限情報に基づき、前記編集指示がなされた第1UI部品の種別に対応する権限を判断する第1判断ステップと、編集後の前記第1UI部品と他の第2UI部品とが重なる場合、前記種別に対する編集の優先度を表す優先情報から取得した前記第1UI部品の種別に対応する優先度と前記第2UI部品の種別に対応する優先度とに基づき、前記第1UI部品の編集が可能か否かを判断する第2判断ステップと、前記第1及び第2判断ステップの判断結果に基づき、前記第1UI部品の編集を制御する編集制御ステップと、をコンピュータに実行させるための編集プログラム。しかし、特許文献1の技術によれば、UI部品1つ1つにアクセス権等の情報を記載したメタ情報が必要となる。よって、新しいUI部品を追加した際に、例えそのUI部品が既存のものと同じようなものであっても、そのメタ情報にアクセス権を追加する必要があるという問題があった。さらに、UI部品のカスタマイズをした際、UI部品同士が干渉重なるなどした場合に、どのUI部品のアクセス権を優先すべきかの判断が難しいという問題があった。そこで、本発明は上記問題に鑑みてなされたものであり、操作画面のUI部品やユーザの権限を効率的に管理することで、カスタマイズを容易にすることができる画像形成装置、編集方法及び編集プログラムを提供することを目的とする。本発明の一局面の画像処理装置は、UI部品の各種別に対し、操作者の編集権限が設定された権限情報を記憶する第1記憶手段と、前記種別に対する編集の優先度を表す優先情報を記憶する第2記憶手段と、編集画面を表示制御し、操作画面内の各UI部品の編集指示を受け付ける操作手段と、前記操作手段が編集指示を受け付けた第1UI部品の種別に対応する権限を、前記権限情報に基づき判断する第1判断手段と、編集後の前記第1UI部品と他の第2UI部品とが重なる場合、前記優先情報から取得した前記第1UI部品の種別に対応する優先度と前記第2UI部品の種別に対応する優先度とに基づき、前記第1UI部品の編集が可能か否かを判断する第2判断手段と、前記第1及び第2判断手段の判断結果に基づき、前記第1UI部品の編集を制御する編集制御手段と、を備える。また、本発明の他の局面の編集方法は、画像形成装置に実行される編集方法であって、編集画面を表示制御し、操作画面内の各UI部品の編集指示を受け付ける操作ステップと、UI部品の各種別に対し、操作者の権限が設定された権限情報に基づき、前記編集指示がなされた第1UI部品の種別に対応する権限を判断する第1判断ステップと、編集後の前記第1UI部品と他の第2UI部品とが重なる場合、前記種別に対する編集の優先度を表す優先情報から取得した前記第1UI部品の種別に対応する優先度と前記第2UI部品の種別に対応する優先度とに基づき、前記第1UI部品の編集が可能か否かを判断する第2判断ステップと、前記第1及び第2判断ステップの判断結果に基づき、前記第1UI部品の編集を制御する編集制御ステップと、を有する。また、本発明は、本発明の編集方法を実行するためのプログラムを記録した記録媒体をコンピュータに読み取らせて実現することも可能である。本発明によれば、操作画面のUI部品やユーザの権限を効率的に管理することで、カスタマイズを容易にすることができる。以下、本発明の実施例を図面に基づいて説明する。[実施例1]<ハードウェア>図1は、実施例1におけるMFP1のハードウェアの一例を示すブロック図である。図1に示すように、MFP1は、制御部11、主記憶部12、補助記憶部13、外部記録装置I/F部14、ネットワークI/F部15、操作部16、表示部17、エンジン部18を含む。これら各構成は、バスを介して相互にデータ送受信可能に接続されている。制御部11は、コンピュータの中で、各装置の制御やデータの演算、加工を行うCPUである。また、制御部11は、主記憶部12や補助記憶部13に記憶されたプログラムを実行する演算装置であり、入力装置や記憶装置からデータを受け取り、演算、加工した上で、出力装置や記憶装置に出力する。主記憶部12は、ROMReadOnlyMemoryやRAMRandomAccessMemoryなどであり、制御部11が実行する基本ソフトウェアであるOSやアプリケーションソフトウェアなどのプログラムやデータを記憶又は一時保存する記憶装置である。補助記憶部13は、HDDHardDiskDriveなどであり、アプリケーションソフトウェアなどに関連するデータを記憶する記憶装置である。外部記録装置I/F部14は、USBUniversalSerialBusなどのデータ伝送路を介して接続された記録媒体19例えば、フラッシュメモリ、SDカードなどとMFP1とのインタフェースである。また、記録媒体19に、所定のプログラムを格納し、この記録媒体19に格納されたプログラムは外部記録装置I/F部14を介してMFP1にインストールされ、インストールされた所定のプログラムはMFP1により実行可能となる。ネットワークI/F部15は、有線及び/又は無線回線などのデータ伝送路により構築されたLANLocalAreaNetwork、WANWideAreaNetworkなどのネットワークを介して接続された通信機能を有する周辺機器とMFP1とのインタフェースである。操作部16や表示部17は、キースイッチハードキーとタッチパネル機能GUIのソフトウェアキーを含む:GraphicalUserInterfaceを備えたLCDLiquidCrystalDisplayとから構成され、MFP1が有する機能を利用する際のUIUserInterfaceとして機能する表示及び/又は入力装置である。エンジン部18は、画像データの入出力ユニットとして、紙原稿の読み取り転写紙への印刷を行う。エンジン部18は、スキャナエンジンなどをさらに備えてもよい。<構成>次に、実施例1におけるMFP1の機能について説明する。図2は、実施例1におけるMFP1の機能の一例を示すブロック図である。図2に示すMFP1は、記憶手段101、操作手段104、判断手段105、編集制御手段106を含む。記憶手段101は、各操作画面の画面データを記憶したり、操作画面の各UI部品のデータを記憶したりする。また、記憶手段101は、権限情報記憶手段102、優先情報記憶手段103を含む。権限情報記憶手段102は、UI部品の各種別に対し、操作者の権限が設定された権限情報を記憶する。UI部品の種別とは、例えば、ボタン、テキスト、リストボタン、入力エリア、状態表示エリアなどである。UI部品の種別に対する操作者の権限とは、例えば、テキストのUI部品に対し、Aさんは編集可又はBさんは編集不可というような権限である。優先情報記憶手段103は、UI部品の種別に対する編集の優先度を表す優先情報を記憶する。編集の優先度は、例えば、UI部品の種別に1,2,3などの優先順を付与したり、テキスト>ボタン>リストボタンなどの不等号を用いて優先を表したりする。操作手段104は、操作部16からの各種操作を受け付ける。例えば、操作手段104は、記憶部101内の画面データに基づく操作画面をカスタマイズ編集する編集画面を表示制御し、操作画面内のUI部品の編集指示を受け付ける。UI部品の編集には、サイズの拡大縮小、位置の変更などがある。操作手段104は、編集対象のUI部品と、編集指示内容と、編集を行った操作者ログインユーザ名などを判断手段105に出力する。判断手段105は、UI部品の編集指示に対し、操作者の権限と、優先度とに基づいて編集を許可するか否かを判定する。図3は、判断手段105の機能の一例を示すブロック図である。図3に示す判断手段105は、権限判断手段201、編集可否判断手段202を含む。権限判断手段201は、権限情報記憶手段102に記憶される権限情報を参照して、編集対象のUI部品の種別に対し、操作者に権限があるか否かを判断する。権限判断手段201は、判断結果を編集制御手段106に出力する。編集可否判断手段202は、編集対象のUI部品を編集することで、他のUI部品に影響を与える他のUI部品と干渉する又は重なる場合、この編集を許可するか否かを判断する。他のUI部品に影響を与えるとは、UI部品同士が重なったりすることである。編集可否判断手段202は、優先情報記憶手段103に記憶される優先情報を参照して、編集対象のUI部品の種別と他のUI部品の種別のそれぞれの優先度を取得する。編集可否判断手段202は、編集対象のUI部品の優先度の方が高い場合は、この編集を許可し、編集対象のUI部品の優先度の方が低い場合は、この編集を不可とする。編集可否判断手段202は、判断結果を編集制御手段106に出力する。なお、判断結果は、編集可否判断手段202からの判断結果に一本化してもよい。このとき、権限判断手段201は、判断結果を編集可否判断手段202に出力する。編集可否判断手段202は、操作者に権限がない場合は編集不可を判断結果する。また、編集可否判断手段202は、操作者に権限がある場合でも編集対象のUI部品の優先度が他のUI部品の優先度より低ければ編集不可を判断結果とし、編集対象のUI部品の優先度が他のUI部品の優先度より高ければ編集可を判断結果とする。編集可否判断手段202は、操作者に権限がある場合で、編集対象のUI部品が他のUI部品に影響を与えない場合は編集可を判断結果とする。図2に戻り、編集制御手段106は、判断手段105から取得した結果に基づき、UI部品のカスタマイズを制御する。編集制御手段106は、権限判断手段201からの判断結果が操作者に権限あるであり、編集可否判断手段202からの判断結果が編集可であればUI部品の編集を編集指示に従って実行する。編集制御手段106は、UI部品を編集した画面データを記憶手段101に記憶する。記憶手段101は、編集後の画面データを、操作者ごとに管理してもよい。以上の構成を有することで、UI部品には種別を関連付け、種別毎に権限を確認したりすることができ、既存の権限を流用したりすることができる。編集をすることで、UI部品間が干渉をする場合は、どのUI部品を優先して編集するかを決定することができる。<各種情報>図4は、UI部品の種別の一例を示す図である。図4に示すUI部品の種別は、UI部品に対し、テキスト、ボタン、リストボタン、入力エリア、状態表示エリアなどが定義されている。例えば、このUI部品の種別情報は、記憶部101に記憶されている。図5は、権限情報の一例を示す図である。図5に示す権限情報は、UI部品の種別毎に、操作者それぞれの権限が設定されている。図5に示す○は例えば権限ありカスタマイズ可能を示し、×は権限なしカスタマイズ不可を示す。図6は、優先情報の一例を示す図である。図6に示す優先情報は、種別単位の優先度と組み合わせテーブルとの一例を示す図である。図6に示す種別の単位の優先度は、ボタン>リストボタン>入力エリア>状態表示エリア=テキストとなっている。これは、ボタンの優先度が一番高く、状態表示エリア及びテキストの優先度が一番低いことを示す。図6に示す組み合わせテーブルは、干渉される側とする側のUI部品の種別に対し、どちらを優先するかを示すテーブルである。例えば、干渉する編集対象のUI部品側の種別がボタンであり、干渉される他のUI部品側の種別がテキストである場合、ボタンの優先度が高いため、ボタンの編集が許可されることを示す。また、干渉する側の種別がテキストであり、干渉される側の種別がボタンである場合、ボタンの優先度が高いため、テキストの編集は許可されないことを示す。また、後優先は、お互いの優先度が同じ状態表示エリア=テキストであるため、後からカスタマイズした内容が反映されることを示す。なお、種別単位の優先度が決まれば、組み合わせテーブルは自動生成可能である。よって、組み合わせテーブルは、必ずしも記憶される必要はない。<編集例>次に、図5、6の情報に基づいたカスタマイズの例について説明する。図7は、UI部品同士が干渉する例を示す図である。図7Aは、ボタンを大きくするカスタマイズにより、テキストの一部が見えなくなる例を示す。UI部品の種別のボタンとテキストとでは、ボタンの方が優先度が高い図6参照。Aさんが操作者の場合権限判断手段201は、Aさんがボタンを編集可能かどうか権限があるかどうかを、権限情報を参照して判断する。この場合、権限判断手段201は、権限ありと判断する。編集可否判断手段202は、干渉する側の優先度が高いため、編集可と判断する。よって、編集制御手段106は、この編集は可能であるため、編集を実行する。Bさんが操作者の場合権限判断手段201は、Bさんがボタンを編集可能かどうか権限があるかどうかを、権限情報を参照して判断する。この場合、権限判断手段201は、権限なしと判断する。編集可否判断手段202は、権限判断手段201の判断結果により優先情報を参照するまでもなく編集不可と判断する。よって、編集制御手段106は、この編集は不可であるため編集を実行しない。つまり、Bさんによるボタンのサイズ変更はできない。管理者が操作者の場合権限判断手段201は、管理者がボタンを編集可能かどうか権限があるかどうかを、権限情報を参照して判断する。この場合、権限判断手段201は、権限ありと判断する。編集可否判断手段202は、干渉する側の優先度が高いため、編集可と判断する。よって、編集制御手段106は、この編集は可能であるため、編集を実行する。次に、図7Bは、状態表示エリアを大きくするカスタマイズにより、リストボタンの一部が見えなくなる例を示す。UI部品の種別の状態表示エリアとリストボタンとでは、リストボタンの方が優先度が高い図6参照。Aさんが操作者の場合権限判断手段201は、Aさんが状態表示エリアを編集可能かどうか権限があるかどうかを、権限情報を参照して判断する。この場合、権限判断手段201は、権限ありと判断する。編集可否判断手段202は、干渉される側の優先度が高いため、編集不可と判断する。よって、編集制御手段106は、この編集は不可であるため、編集を実行しない。つまり、Aさんによる状態表示エリアの変更はできない。Bさんが操作者の場合権限判断手段201は、Bさんが状態表示エリアを編集可能かどうか権限があるかどうかを、権限情報を参照して判断する。この場合、権限判断手段201は、権限なしと判断する。編集可否判断手段202は、権限判断手段201の判断結果により優先情報を参照するまでもなく編集不可と判断する。よって、編集制御手段106は、この編集は不可であるため編集を実行しない。つまり、Bさんによる状態表示エリアの変更はできない。管理者が操作者の場合権限判断手段201は、管理者が状態表示エリアを編集可能かどうか権限があるかどうかを、権限情報を参照して判断する。この場合、権限判断手段201は、権限ありと判断する。編集可否判断手段202は、干渉される側の優先度が高いため、編集不可と判断する。よって、編集制御手段106は、この編集は不可であるため、編集を実行しない。つまり、管理者による状態表示エリアの変更はできない。次に、UI部品同士に関連付けが行われている場合、いずれかのUI部品に編集権限があれば、関連付けられたUI部品同士の編集を可能とする例について説明する。図8は、関連付けがUI部品同士の連動関係である場合の例を示す図である。図8Aは、片面集約ボタンa11が選択されている場合、枚数選択のリストボタンa21が連動して表示される例を示す。図8Bは、両面集約ボタンa12が選択されている場合、枚数選択のリストボタンa22が連動して表示される例を示す。図8ABは、集約選択ボタンに枚数選択リストボタンが連動している。例えば、Aさんがリストボタンを編集する場合を考える。このとき、権限判断手段201は、Aさんが枚数選択リストボタンの種別リストボタンを編集可能かどうか権限があるかどうか及び枚数選択リストボタンに連動する集約選択ボタンの種別ボタンを編集可能かどうかを、権限情報を参照して判断する。この場合、権限判断手段201は、ボタンに対して権限ありと判断する。ここで、連動するUI部品のうち、一つでも権限ありのUI部品があれば、権限判断手段201は、連度するUI部品例えば集約選択ボタン、枚数選択リストボタン全てを編集可と判断する。よって、編集制御手段106は、この枚数選択リストボタンの編集は可能であるため、編集を実行する。一般的に、カスタマイズ編集をする場合は、所定のUI部品に対し、意味のある集合単位で行うことが多い。しかしながら、集合単位でアクセスカスタマイズ権限を設定するのは非常に大変である。しかし、煩雑な設定をしなくても、所定の意味のある集合内のUI部品に対し関連付けを行っていれば、その集合内のUI部品の1つに権限がある場合、その集合内のカスタマイズは全て可能とする。これにより、煩雑な設定をしなくても、適切なカスタマイズが可能になる。次に、関連付けの例が排他関係の場合について説明する。図9は、関連付けがUI部品同士の排他関係である場合の例を示す図である。図9Aは、片面集約ボタンが選択されている場合の例を示す。図9Bは、両面集約ボタンが選択されている場合の例を示す。図9Bには、両面集約に必要な開き方向の選択リストボタンa31が表示されている。一方、図9Aには、片面集約の場合、開き方向は不要であるため、開き方向の選択リストボタンa31は表示されない。つまり、開き方向の選択リストボタンa31は、両面集約ボタンa12であれば表示され、片面集約ボタンa11であれば表示されないという排他的な関係にある。このとき、開き方向の選択リストボタンa31は、両面集約ボタンa12と関連付けされる。例えば、Aさんが開き方向の選択リストボタンa31を編集する場合を考える。このとき、権限判断手段201は、Aさんが開き方向の選択リストボタンa31の種別リストボタンを編集可能かどうか権限があるかどうか及び開き方向の選択リストボタンa31に連動する両面集約ボタンa12の種別ボタンを編集可能かどうかを、権限情報を参照して判断する。この場合、権限判断手段201は、ボタンに対して権限ありと判断する。ここで、関連付けられたUI部品のうち、一つでも権限ありのUI部品があれば、権限判断手段201は、関連付けられたUI部品例えば両面選択ボタン、開き方向の選択リストボタン全てを編集可と判断する。よって、編集制御手段106は、この開き方向の選択リストボタンの編集は可能であるため、編集を実行する。なお、関連付けられた関連UI部品情報は、記憶手段101に予め記憶されているとする。判断手段105が、記憶手段101に記憶されている関連UI部品情報を参照して、前述した判断を行う。これにより、開き方向の選択リストボタンのように、排他的な関係を有するUI部品であっても、煩雑な設定をしなくてすむ。また、所定の意味のある集合内のUI部品に対し関連付けを行っていれば、その集合内のUI部品の1つに権限がある場合、その集合内のカスタマイズは全て可能とすることで、煩雑な設定をしなくても、適切なカスタマイズが可能になる。<動作>次に、MFP1の動作について説明する。図10は、実施例1における編集可否判断処理の一例その1を示すフローチャートである。図10に示すステップS101で、判断手段105は、機器に認証されている操作者の権限を、権限情報を参照することでチェックする。ステップS102で、判断手段105は、操作者による編集指示が、権限がある種別のUI部品のカスタマイズであるかを判定する。権限がある種別であればステップS102-YESステップS103に進み、権限がない種別であればステップS102-NOステップS106に進む。ステップS103で、判断手段105は、操作者による編集指示の内容カスタマイズ内容が、他のUI部品に干渉するかを判定する。他のUI部品と干渉すればステップS103-YESステップS104に進み、他のUI部品と干渉しなければステップS103-NOステップS106に進む。ステップS104で、判断手段105は、干渉する編集対象のUI部品と干渉されるUI部品の優先度の関係から、編集をしてもよいかを判定する。干渉するUI部品の優先度の方が高ければステップS104-YESステップS105に進み、干渉されるUI部品の優先度の方が高ければステップS104-NOステップS106に進む。ステップS105で、判断手段105は、操作者による編集指示を、カスタマイズOK編集可と判断する。ステップS106で、判断手段105は、操作者による編集指示を、カスタマイズNG編集不可と判断する。次に、UI部品の関連付けを考慮する場合の判断処理について説明する。図11は、編集可否判断処理の一例その2を示すフローチャートである。図11に示す処理は、図10に示すステップS106の後に行われる。ステップS201で、判断手段105は、ステップS106でカスタマイズNGと判断されたかを判定する。カスタマイズNG編集不可と判断されればステップS201-YESステップS202に進み、カスタマイズOK編集可と判断されればステップS201-NO処理を終了する。ステップS202で、判断手段105は、カスタマイズ対象のUI部品と連動関係にあるUI部品が操作画面上にあるかを判定する図8参照。連動関係にあるUI部品があればステップS202-YESステップS203に進み、連動関係にあるUI部品がなければステップS202-NO処理を終了する。ステップS203に進み、判断手段105は、連動関係にあるUI部品に対して、操作者はカスタマイズ権限があるかを判定する。カスタマイズ権限がある場合ステップS203-YESステップS204に進み、カスタマイズ権限がない場合ステップS203-NO処理を終了する。ステップS204で、判断手段105は、カスタマイズ対象のUI部品に対し、カスタマイズOK編集可と判断する。図12は、編集可否判断処理の一例その3を示すフローチャートである。図12に示す処理は、図10に示すステップS106の後に行われる。ステップS301で、判断手段105は、ステップS106でカスタマイズNG編集不可と判断されたかを判定する。カスタマイズNG編集不可と判断されればステップS301-YESステップS302に進み、カスタマイズOK編集可と判断されればステップS301-NO処理を終了する。ステップS302で、判断手段105は、カスタマイズ対象のUI部品と排他関係にあるUI部品が操作画面上にあるかを判定する図9参照。排他関係にあるUI部品があればステップS302-YESステップS303に進み、排他関係にあるUI部品がなければステップS302-NO処理を終了する。ステップS303に進み、判断手段105は、排他関係にあるUI部品に対して、操作者はカスタマイズ権限があるかを判定する。カスタマイズ権限がある場合ステップS303-YESステップS304に進み、カスタマイズ権限がない場合ステップS303-NO処理を終了する。ステップS304で、判断手段105は、カスタマイズ対象のUI部品に対し、カスタマイズOK編集可と判断する。以上、実施例1によれば、UI部品の種別単位で編集権限を管理することで、操作画面のUI部品やユーザの権限を効率的に管理することで、カスタマイズを容易にすることができる。また、実施例1によれば、種別単位で管理を行うことで、新しいUI部品が追加された場合でも、編集権限を流用することができる。また、実施例1によれば、UI部品の種別間の優先度から編集の可否を判断するため、UI部品が干渉した場合に、容易に編集可否を判断することができる。また、実施例1によれば、所定の意味のある集合内のUI部品に対し関連付けを行っていれば、その集合内のUI部品の1つに権限がある場合、その集合内のカスタマイズは全て可能とすることで、煩雑な設定をしなくても、適切なカスタマイズが可能になる。[実施例2]次に、実施例2におけるMFP2について説明する。実施例2では、記憶手段101に記憶される権限情報や優先情報を編集する。実施例2におけるMFP2のハードウェアは実施例1と同様であるため、その説明を省略する。<構成>図13は、実施例2におけるMFP2の機能の一例を示すブロック図である。図13に示すMFP2は、権限情報編集手段301、優先情報編集手段302、記憶手段101、操作手段104、判断手段105、編集制御手段106を含む。図13に示す機能において、図2に示す機能と同様のものは同じ符号を付し、その説明を省略する。権限情報編集手段301は、図5に示す権限情報にアクセスし、編集を行う。例えば、権限情報の編集画面を表示制御し、操作者からの編集指示を権限情報に反映させる。権限情報編集手段301は、例えば、操作者の権限を変更する。図14は、操作者の権限を変更する例を説明するための図である。図14に示す例では、権限情報編集手段301は、Bさんの入力エリアの権限を×:カスタマイズ不可から○:カスタマイズ可に変更する。また、権限情報編集手段301は、管理者のリストボタンの権限を○:カスタマイズ可から×:カスタマイズ不可に変更する。これにより、種別毎の権限を編集することができ、操作者の環境に合うよう最適な権限情報にすることができる。権限情報編集手段301は、UI部品の種別を新規に追加することもできる。図15は、UI部品の種別を新規に権限情報に追加する例を説明するための図である。図15に示す例では、権限情報編集手段301は、種別アイコンを新規に権限情報に追加する。このアイコンには、Aさん、Bさん、管理者全てに対し、○:カスタマイズ可が設定される。これにより、新しいUI部品の種別を追加することができ、新しいUI部品も権限情報に従って編集することができる。優先情報編集手段302は、図6に示す優先情報にアクセスし、編集を行う。例えば、優先情報の編集画面を表示制御し、操作者からの編集指示を優先情報に反映させる。優先情報編集手段302は、例えば、種別単位の優先度を変更する。図16は、種別単位の優先度を変更する例を説明するための図である。図16に示す例では、優先情報編集手段302は、状態表示エリアをテキストよりも優先度を高くする変更を行う。この変更に伴い、組み合わせテーブルも自動で変更される図16参照。干渉する側状態表示エリア及び干渉される側テキスト、干渉する側テキスト及び干渉される側状態表示エリアが後優先から状態表示エリアに変更される。これにより、種別間の優先度を編集することができ、操作者の環境に合うよう最適な優先情報にすることができる。優先情報編集手段302は、UI部品の種別を新規に追加することもできる。図17は、UI部品の種別を新規に優先情報に追加する例を説明するための図である。図17に示す例では、優先情報編集手段302は、種別アイコンを、状態表示エリア及びテキストと同じ優先度として追加する。この追加に伴い、組み合わせテーブルも自動で変更される図17参照。干渉するUI部品間の優先度が同じ場合は後優先となる。これにより、新しいUI部品の種別を追加することができ、新しいUI部品も種別間の優先情報に従って編集することができる。以上の構成により、MFP2は、権限情報の権限を編集したり、UI部品の種別の権限を新規に追加したり、容易に編集することができる。また、MFP2は、優先情報の権限を編集したり、UI部品の種別の優先度を追加したり、容易に編集することができる。<動作>次に、実施例2におけるMFP2の動作について説明する。図18は、権限を変更する処理の一例を示すフローチャートである。図18に示すステップS401で、権限情報編集手段301は、権限情報記憶手段102から権限情報を取得する。ステップS402で、権限情報編集手段301は、UI部品の種別、操作者の情報から権限情報に設定された権限値を検索し、この権限値を変更する。ステップS403で、権限情報編集手段301は、ステップS402の変更内容に基づいて、権限情報記憶手段102に記憶される権限情報を更新する図14参照。図19は、新規種別を権限情報に追加する処理の一例を示すフローチャートである。図19に示すステップS501で、権限情報編集手段301は、権限情報記憶手段102から権限情報を取得する。ステップS502で、権限情報編集手段301は、新規UI部品の種別を権限情報に追加し、適切な権限値を入力する。ステップS503で、権限情報編集手段301は、ステップS502の新規種別の追加に基づいて、権限情報記憶手段102に記憶される権限情報を更新する図15参照。図20は、優先度を変更する処理の一例を示すフローチャートである。図20に示すステップS601で、優先情報編集手段302は、優先情報記憶手段103から優先情報を取得する。ここでは、優先情報は、種別単位の優先度及び組み合わせテーブルをいう。ステップS602で、優先情報編集手段302は、種別単位の優先度を変更し、組み合わせテーブルを優先度の変更に従って適切に変更する。ステップS603で、優先情報編集手段302は、ステップS602の変更内容に基づいて、優先情報記憶手段103に記憶される優先情報を更新する図16参照。図21は、優先度に種別を追加する処理の一例を示すフローチャートである。図21に示すステップS701で、優先情報編集手段302は、優先情報記憶手段103から優先情報を取得する。ここでは、優先情報は、種別単位の優先度及び組み合わせテーブルをいう。ステップS702で、優先情報編集手段302は、優先度に新規種別を追加して、組み合わせテーブルを新規種別の優先度に従って適切に変更する。ステップS703で、優先情報編集手段302は、ステップS702の変更内容に基づいて、優先情報記憶手段103に記憶される優先情報を更新する図17参照。以上、実施例2によれば、権限情報の権限を編集したり、UI部品の種別の権限を新規に追加したり、容易に編集することができる。また、実施例2によれば、優先情報の権限を編集したり、UI部品の種別の優先度を追加したり、容易に編集することができる。[実施例3]次に、実施例3におけるMFP3について説明する。実施例3のMFP3は、編集が不可と判断された場合、その旨を通知する。また、MFP3は、カスタマイズが可能な編集内容を合わせて通知する。実施例3におけるMFP3のハードウェアは実施例1と同様であるため、その説明を省略する。<構成>図22は、実施例3におけるMFP3の機能の一例を示すブロック図である。図22に示すMFP3は、記憶手段101、操作手段104、判断手段105、編集制御手段106、通知手段401を含む。図22に示す機能において、図2に示す機能と同様のものは同じ符号を付し、その説明を省略する。通知手段401は、判断手段105によりカスタマイズNGと判断された旨の通知を受ける。通知手段401は、UI部品の編集がNGである権限がないことを表示部17に表示する図23参照。図23は、エラー通知の一例その1を示す図である。図23に示す例では、エラー通知として権限がありませんと画面に表示される。また、通知手段401は、操作者と干渉されるUI部品の種別とから、編集可能なUI部品とその内容とをエラー通知に含める図24。図24は、エラー通知の一例その2を示す図である。図24に示す例では、エラー通知と共に、カスタマイズ可能なUI部品の種別が通知される。例えば、図24に示す例では、通知手段401は、操作者の権限に応じてテキスト部品ならカスタマイズできる旨を通知する。また、通知手段401は、UI部品同士が干渉する場合、干渉してもよいUI部品の種別ボタンを判断し、ボタンなら重ねることができる旨を通知する。以上の構成により、編集不可の場合に、その旨を通知することができる。また、編集不可の場合に、編集可能なUI部品の種別や編集内容を通知することもできる。<動作>次に、実施例3におけるMFP3の動作について説明する。図25は、実施例3におけるエラー通知処理の一例その1を示すフローチャートである。図25に示すステップS801で、通知手段401は、判断手段105によりカスタマイズNG編集不可と判断されたかを判定する。カスタマイズNGであればステップS801-YESステップS802に進み、カスタマイズNGでなければステップS801-NO処理を終了する。ステップS802で、通知手段401は、権限がありませんというエラー表示を行って、操作者に通知する。図26は、実施例3におけるエラー通知処理の一例その2を示すフローチャートである。図26に示すステップS901で、通知手段401は、判断手段105によりカスタマイズNG編集不可と判断されたかを判定する。カスタマイズNGであればステップS901-YESステップS902に進み、カスタマイズNGでなければステップS901-NO処理を終了する。ステップS902で、通知手段401は、権限情報、優先情報種別単位の優先度と組み合わせテーブルに基づき、MFP3に認証されている操作者にカスタマイズ可能なUI部品の種別を取得する。ステップS903で、通知手段401は、権限がない旨と編集可能なカスタマイズ内容を表示部17に表示して、操作者に通知する。以上、実施例3によれば、編集不可の場合に、その旨を通知することができたり、編集可能なUI部品の種別や編集内容を合わせて通知することもできたりする。以上、本発明の実施例について詳述したが、本発明は係る特定の実施例に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形変更が可能である。また、前述した実施例の構成要素を全部又は複数を組み合わせて画像形成装置を構成することも可能である。なお、実施例において説明した処理内容をプログラムとし、このプログラムをコンピュータに実行させて前述した処理を画像形成装置に実行させることも可能である。また、このプログラムを記録媒体に記録し、このプログラムが記録された記録媒体をコンピュータに読み取らせて、前述した処理を画像形成装置に実行させることも可能である。"