Неверное имя файла шрифта (imagettfbox)
Этот вопрос задавался снова и снова, но я не смог найти правильный ответ на мою проблему. Как небольшое примечание, весь код работал отлично, прежде чем мы переместили файл класса из /application/lib/class to/library/class. Я попытался сыграть с GDFONTPATH, относительными, абсолютными путями с расширением файла и без него безрезультатно. Вот некоторые из строк, которые мы пробовали до сих пор:
putenv('GDFONTPATH=' . realpath(dirname(dirname(__FILE__)).DIRECTORY_SEPARATOR.'fonts')); /*1*/ $FontName = dirname(dirname(__FILE__)).DIRECTORY_SEPARATOR.'fonts'.DIRECTORY_SEPARATOR.basename($FontName,'.ttf'); /*2*/ $FontName = '\pChart\fonts\\'.basename($FontName); /*3*/ $FontName =basename($FontName); $coords = imagettfbbox($FontSize, 0, $FontName, $Text); Несколько комбинаций этих попыток также использовались безрезультатно. Я действительно недоволен этой проблемой, поскольку # 1, когда echo’ed дает полный путь, который открывает правильный файл шрифта, если он скопирован/вставлен в win explorer. Это может помочь узнать абсолютный путь к файлу, который получает ошибку и путь к имени шрифта.
C:\wamp\www\application_bundle\Library\pChart\class\pImage.class.php C:\wamp\www\application_bundle\Library\pChart\fonts\arialuni.ttf Мы сталкиваемся с этой проблемой на всех платформах разработчиков (Win, Mac и Linux). PHP 5.3.13 Благодарим вас за помощь. Изменить: Кажется, что файл не найден/сервер не смотрит в нужную папку. Если кто-то может помочь устранить проблему, указав, как определить, какой путь пытается открыть GD, действительно помощь.
Вы пробовали косую черту, верно? PHP на Windows понимает и то и другое, но что-то глубокое в GD может и не быть.
Сегодня мы попытались использовать другой шрифт, обновить файлы библиотеки и до сих пор без изменений.
@Salketer Очень трудно (я боюсь, даже невозможно) решить эту проблему, потому что мы не можем воспроизвести ошибку, но я могу сказать, что я буду делать в этой ситуации. На вашем месте я бы села и записала каждую мелочь (даже если вы думаете, что она не связана с проблемой), которая изменилась с рабочей версии, а затем проанализировала бы пошагово.
4 ответа
Мы выяснили, как заставить его работать.
Короче говоря, мы включали файл класса, а затем вызывали методы для записи текста. Мы делали что-то вроде этого:
$classPath = 'pChart/'; include($classPath.'/class/pImage.class.php'); //. inside the pImage.class we passed font like this: $FontName = $classPath.'/fonts/arialuni.ttf'; imagettfbbox($FontSize, 0, $FontName, $Text) Это не сработало, что мы делали до или после. Пока мы не изменили $classPath на
Обратите внимание, что они (или должны) указывать точно в ту же папку, что и код, выполняемый из файла в корне библиотеки.
Мы пытались найти, почему абсолютные пути не работали, но не могли воспроизвести ошибку в изолированной среде, поэтому в нашей архитектуре есть что-то подозрительное.
Я знаю, что на это был дан ответ и принят, но я не видел, чтобы кто-то задумывался о том, почему это решение работает и что было неправильно в первую очередь.
Краткое описание проблемы
Текущая рабочая директория устанавливается в точке php, которая обрабатывает запрос, и все относительные пути разрешаются на основе текущего рабочего каталога, а не каталога файла, на который указан путь.
Длинное описание проблемы
Относительные пути в php разрешаются на основе текущего рабочего каталога.
В целях тестирования вы всегда можете увидеть, что представляет собой текущий рабочий каталог, вызывая getcwd
Это значение изначально поступает на http-запрос в качестве каталога, содержащего файл, который веб-сервер первоначально передал запросу на php.
Так, например, если вы перейдете к http://www.mydomain.com/index.php, текущий рабочий каталог будет таким же, как и корень документа ( $_SERVER[«DOCUMENT_ROOT»] )
Для запроса CLI cwd — это каталог, в котором вы находитесь, когда вы выполняете команду. Поэтому, если я нахожусь в /home/orangepill , и я запустил /usr/bin/php /path/to/file.php , cwd будет /home/orangepill .
Это вызывает проблему для относительных ссылок на файлы внутри включенных файлов.
Давайте рассмотрим этот пример.
- Клиент перейдет на сайт www.mydomain.com
- Apache имеет index.php, установленный в директиве DirectoryIndex, и apache находит файл index.php в корневом каталоге документа. Текущий рабочий каталог установлен в корень документа.
- /index.php содержит строку include «library/myclass.php»; $ _SERVER [ «DOCUMENT_ROOT» ]. «/Library/myclass.php» существует и все хорошо
- myclass.php содержит строку include(«myclass_helper.php»); , которая разрешает $_SERVER [ «DOCUMENT_ROOT» ]. «/myclass_helper.php». (помните, что относительные ссылки разрешаются относительно текущего рабочего каталога)
- $_SERVER[«DOCUMENT_ROOT»].»/myclass_helper.php» не существует на самом деле в $_SERVER[«DOCUMENT_ROOT»].»/library/myclass_helper.php»
Вероятно, вы, но ждите. Я испытал различное поведение в своих сценариях, включив его в include. Причина этого заключается в том, что include и require language constructs (вместе с несколькими другими командами файловой системы) пытаются включить относительные пути из каждого из путей, указанных в директиве include php. Итак, в приведенном выше примере, если библиотечная директория с корнем документа существовала внутри включенных путей, тогда все будет работать так, как ожидалось.
Оптовое решение для требуемых файлов относительно текущего файла состоит в том, чтобы структурировать ваши пути include, используя контекстную константу __DIR__ . Таким образом, вы использовали бы include __DIR__.»/myclass_helper.php»; ( include dirname(__FILE__).»/myclass_helper.php в средах pre PHP 5.3), и во время выполнения это фактически превратило бы ваш относительный путь в абсолютный путь, основанный на местоположении файла, делающего include.
Для обычных включенных каталогов я привык задавать несколько часто используемых мест для использования с относительными ссылками файловой системы. например
define ("APPLICATION_PATH", realpath($_SERVER["DOCUMENT_ROOT"]."/application"); define ("LIBRARY_PATH", realpath($_SERVER["DOCUMENT_ROOT"]."/library"); define ("CONFIG_PATH", APPLICATION_PATH."/etc/"; Это дает вам множество опорных точек для включения путей относительно.
Спасибо за ваш ответ. Это заслуживает некоторого внимания. Но здесь проблема не должна быть такой же, как описано . Включение файла относительно пути включения работает. Файл pChart был правильно включен, используя просто ‘pChart /’, так как он находится в библиотеке, но шрифт будет найден, только если мы включим файл, используя ‘../library/pChart’. Если я все еще что-то упускаю, это не имеет для нас смысла.
Это указывало бы на то, что текущим рабочим путем был каталог, совместно использующий родителя с каталогом библиотеки. Где находится путь к файлу php, который первым обработал запрос apache.
index.php, получившему запрос, должен был получить доступ к этому пути от родителя библиотеки: ./app1/www/
Как изменить значок для определенного типа файла?
Я пытаюсь изменить значок для application/x-hwp файлы. Я добавил иконки в нужные места и проверил их с помощью assoGiate (после прочтения этой темы). Это показывает, что мой нужный значок связан с типом файла. Тем не менее, Наутилус все еще показывает старую икону. Как я могу заставить Наутилус показывать правильный значок?
4 ответа
Вот набор инструкций, которые должны получить пользовательский значок для файлов hwp.
- Проверьте, существует ли тип MIME: grep ‘hwp’ /etc/mime.types
sudo cp PathToIcon/application-x-hwp.svg /usr/share/icons/gnome/scalable/mimetypes Основная хитрость заключается в том, чтобы правильно узнать, где находятся реальные значки.
Чтобы определить это, давайте проанализируем значки HTML. Соглашение об именах для значков такое же, как и для MIME-типа, только / заменяется на — и заглавные буквы не допускаются. Т.е. MIME-тип, скажем, text/x-changelog будет иметь иконку с именем text-x-changelog.svg (или же png ). MIME-тип для HTML text/html , Так что его иконка будет text-html.* Если мы запустим команду
find /usr/share/icons/ -type f | grep 'text-html\.' мы получим несколько мест, где расположены эти иконки:
/usr/share/icons/Humanity/mimes/ /usr/share/icons/gnome/NNxNN/mimetypes/ /usr/share/icons/HighContrast/scalable/mimetypes/ Если мы посетим каждого из них с Наутилусом, мы увидим, что Humanity/ папка содержит наши текущие иконки, gnome/ — некоторые старые. HighContrast/ нас не интересует. Таким образом, чтобы изменить какой-либо значок, мы должны заменить значки, расположенные в Humanity/ папка.
Также обратите внимание, что text-html.svg значки, которые можно масштабировать и которые должны быть помещены в scalable вложенные папки (что должно быть логично) вместо этого помещаются в папки разных размеров, так же, как растровые файлы PNG.
После замены значков (во всех подпапках в соответствии с их размерами) на нужные необходимо обновить кеш значков:
sudo gtk-update-icon-cache /usr/share/icons/Humanity Есть еще один способ определить приоритетность схем значков — проверить их index.theme файлы. Если мы посмотрим внутрь /usr/share/icons/Humanity/index.theme , посмотрим:
Это означает, что значки из gnome а также hicolor папки будут иметь меньший приоритет, чем папки из Humanity , Это объясняется здесь.
Как ни странно, Наутилус не подчиняется этим правилам наследования. Когда я добавил новый MIME-тип, я попытался поместить его значки в /usr/share/icons/gnome/ , /usr/share/icons/hicolor , ~/.local/share/icons/hicolor Обновление иконки базы на каждом шаге — все напрасно. Эти значки правильно отображались в assogiate на первой вкладке, но никогда в Наутилусе. Но когда я поместил их в Humanity папки и обновленные иконки базы данных, они появились сразу.
NB Все это относится к теме значков по умолчанию. Если вы используете какую-то собственную тему значков, вы должны проверить, где находятся настоящие значки, и вместо этого добавить / изменить значки. Также в более новых дистрибутивах эти правила наследования могут измениться. Затем вы должны найти новую папку, в которой хранятся фактические значки (если это не так Humanity больше), как объяснено ранее.