Так вот, когда HTML в браузере к нему подключается CSS, а когда в вордовском файле, там чистый HTML, следовательно таблица выглядит не камильфо
Можно ли какнибудь ворду передать CSS?
Конечно. Создавайте файл RTF через одну из библиотек для этого предназначенных.
Если файл стандартный и небольшой, как и стили то читайте описание формата RTF и генерируйте в скрипте коды соответствующие вашим стилям.
Прочитал по диагонали (из-за флуда) посты. Извиняюсь если повторюсь, но овтечу на пост топикстартера.
При организации потокового вещания через интернет у вас должно быть 3 сегмента. 1 - генератор потока, 2 - сервер потокового вещания, 3 - клиент принимающий и воспроизводящий поток. Что из этого вы хотите реализовать на PHP? Теоретически можно абсолютно любой элемент. Практически на пхп можно написать интернет-морду радиостанции со списком треков, текущими треками, программой передач, плеером и проч. В качестве генератора потока может быть, например любая радиостанция, программа воспроизведения аудио, winamp, как вам предлагали, аналоговые устройства (микрофон, электрогитара, хоть бубен...). В последнем случае вам будет необходим декодер, преобразующий поток в цифровой.
Сервер потокового вещания принимает поток и раздает клиентам. Я видел немало извращений на php, так что можно ещё написать на нем и сервер потокового вещания. Но лучше не делать велосипед, а взять например icecast. Бесплатен и ничуть не хуже коммерческих аналогов. Все. вставляете плеер подключенный к вашему серверу на сайт и наслаждаетесь.
если без возможности вывода средств делать то игра ничем не будет отличатся от конкурентов и игра не будет востребованной. а если делать с выводом средств, как казино, то игра будет востребованной. Мелкий, спасибо за наводку, пойду на другой форум за инфой
По закону это азартная игра. Есть рпг-игры с выводом средств у нас, просто не все знают что они подпадают под категорию азартных. Не так известны и их не трогают.
Хостись не в рф и регистрируй фирму не в рф и ты ничто никому не должен тут.
вроде все работает как надо, но жутко тормозит когда начинаю заполнять БД прайсами.
1. Указанный вами код не заполняет бд прайсами поэтому непонятно какое отношения к нему имеет загрузка прайсов и связанные с этим "тормоза".
2. Рекомендую приводить данный перед загрузкой в базу к единому виду, а не обрезать их перед выводом. Потому что в этом случае вам придется произвести эту операцию только один раз, а не каждый раз перед выводом результатов поиска.
1) если у вас есть фотошоп то в папке fonts ос windows у вас их должно быть сотни и тысячи.
2) см 1. гуглить за вас не хочется.
3) вы даете в css браузеру ссылку на файл шрифта, оттуда и поймет.
Цитата:
Как делать верстку, если в PSD-ке используется экзотический шрифт, а у меня его нету и скачать не могу?
Картинкой.
4)
Цитата:
В photoshop надпись выглядит не так, как в браузере, хотя шрифт и его размер установил такой же, как в photoshop
В фотошопе никогда не будет все выглядить так, как в браузере, потому что фотошоп это графический редактор, а не браузер.
Чтобы приблизить внешний вид шрифтов к их отображению на реальной веб-странице уберите их сглаживание, уберите или бросьте все параметры текстовой палитры, включая отступы и выравнивания.
Использование такой структуры, как у вас, возможно только в одном единственном случае, когда вы пишите для уже написанного большого приложения где сложно изменить структуру бд.
Да это кстати интересная мысль но хотелось бы всё таки узнать где лучше хранить большой обём информации в базе или текстовом файле?
И стоит ли создавать историю для каждого вида пользователя то есть: для ПРОДОВЦА, АГЕНТА, ЭКСПЕРТА, АДМИНА, или стоить просто как я и задумал разделить просто по ID участника?
Все зависит от того как часто вам будет нужно работать с этими данными и в каком виде. В принципе ваша база и так в любом случае должна хранить все данные по операциям платежным, по юзерам например в таблице юзеров, по заказам в таблице заказов по текущим операциям в другой таблице и т.д. вопрос в том стоит ли собирать эти же данные в отдельную таблицу для более простого быстрого извлечения.
Данные не должны дублироваться в рамках одной базы данных в двух разных таблицах. Хотите единые отчет - очень-много-табличный запрос.
Поэтому я просто все операции с платежами вел в виде отдельного текстового лога, создаваемого каждые сутки и удаляемого раз в месяц.
считываем данные с файла по примерному времени операции и говорим пользователю почему не прошел платеж (на самом деле это должно делаться автоматом, а лог-файл служит просто для удобного просмотра и работы с последовательностью операций в тех случаях когда не надо вносить изменения в бд). Реализовано в виде одного класса с методами записи отличающимися в зависимости от типа операции - оплата, возврат, запрос сервера платежной системы, приход статус успешной оплаты, запись ошибки оплаты и т.д.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 2118
