Research/all-in-one publishing - Revision history

Arjensuijker at 12:36, 24 September 2015

2015-09-24T12:36:51Z

← Older revision		Revision as of 12:36, 24 September 2015
Line 97:		Line 97:

	== Conclusion ==		== Conclusion ==
			The main problem at this moment is that a lot of software is just not standards compliant and does not provide sufficient documentation. Many things simply don't work, and other things only work when using proprietary methods. Epub proved to be the most problematic format to create, as most epub readers have very limited support for layout and styling. This may not be a problem because users are not used to their ebooks looking pretty, but it is quite disappointing for designers. The other output formats gave much better results, but the overall lack of standard compliantness made the process much more time consuming than it should be.

	Overall, this workflow proved to work well. We needed some time to get used to the process, but it already appears to be a viable alternative to traditional workflows. The biggest challenge is probably that every member of the development team needs a fair bit of technical skill together with an eye for design. If such a team is available, this process can streamline the entire publication process.		Overall, this workflow proved to work well. We needed some time to get used to the process, but it already appears to be a viable alternative to traditional workflows. The biggest challenge is probably that every member of the development team needs a fair bit of technical skill together with an eye for design. If such a team is available, this process can streamline the entire publication process.

Arjensuijker at 12:03, 24 September 2015

2015-09-24T12:03:49Z

← Older revision		Revision as of 12:03, 24 September 2015
Line 1:		Line 1:
	== Introduction ==		== Introduction ==

	The core of our research is the development of '''a workflow in which HTML and CSS''' files are used as the '''primary source for a publication'''. This ~~publication is then made available for~~ print, epub and ~~a responsive website~~. This approach ~~was chosen because it can potentially improve~~ the publication workflow ~~for the following reasons~~:		The core of our research is the development of '''a workflow in which HTML and CSS''' files are used as the '''primary source for a publication'''. These technologies were originally designed for creating only websites, but in recent years many '''printing capabilities have been added'''. This results in a '''unified''' file format that can be used to publish to '''print, epub, web and mobile'''. This approach offers some unique improvements on the publication workflow:

	* ~~Both the~~ '''~~design~~ and ~~the~~ content can be ~~updated~~ at any time~~'''~~, fully independently of each other.		* '''Design and content are separate''', both can be changed at any time, fully independently of each other.
	* '''Every ~~update~~''' in content or design can be exported to '''every available publication medium'''.		* '''Every change''' in content or design can be exported to '''every available publication medium''' with the press of a button.
	* '''HTML and CSS are very widespread transparent file formats''' that have been used for decades without much change, and will remain this way for years to come. This makes them much more suitable for '''digital archiving''' than most proprietary formats.		* '''HTML and CSS are very widespread transparent file formats''' that have been used for decades without much change, and will remain this way for years to come. This makes them much more suitable for '''digital archiving''' than most proprietary formats.
	* For largely the same reasons, the resulting publication is very '''suitable for (collaborative) reuse and redesign'''.		* For largely the same reasons, the resulting publication is very '''suitable for (collaborative) reuse and redesign'''.

Arjensuijker at 07:10, 24 September 2015

2015-09-24T07:10:00Z

← Older revision		Revision as of 07:10, 24 September 2015
Line 10:		Line 10:
	=== About the process ===		=== About the process ===

	For this research, we have chosen to take an existing publication and explore how it could be rebuilt from scratch using our newly developed workflow. The original publication was only designed for print (a pdf). Our goal was to replicate this design as closely as possible with our new print version, and adapt the design to also fit the other media.		For this research, we have chosen to take an existing publication and explore how it could be '''rebuilt from scratch using our newly developed workflow'''. The original publication was only designed for print (a pdf). Our goal was to replicate this design as closely as possible with our new print version, and adapt the design to also fit the other media.

	The global process consisted of the following steps:		The global process consisted of the following steps:

	# The original Word documents with the contents of the publication were converted to html files using Pandoc conversion software.		# The original '''Word documents''' with the contents of the publication were converted '''to html files using Pandoc''' conversion software.
	# These html files were 'cleaned up', deleting everything design-related and leaving only structural information.		# These html files were ''''cleaned up'''', deleting everything design-related and leaving only structural information.
	# Additional HTML was added to improve semantic value and facilitate CSS styling.		# '''Additional HTML''' was added to improve '''semantic value''' and facilitate '''CSS styling'''.
	# CSS stylesheets were created for every output format.		# '''CSS stylesheets''' were created for every output format.
	# The outputs were created and tested using Pandoc (for epub), PrinceXML and Weasyprint (for pdf), Chrome (for responsive web) and Firefox (for direct browser print) and checked for consistency. PrinceXML is proprietary software, Weasyprint is not.		# The outputs were '''created and tested''' using Pandoc (for epub), PrinceXML and Weasyprint (for pdf), Chrome (for responsive web) and Firefox (for direct browser print) and checked for consistency. PrinceXML is proprietary software, Weasyprint is not.

	Of course the process wasn't as linear as it appears here. The process can be better described as being iterative, looping through the steps continuously. The commits list in github can be a good portrait of this iteration. Available at: https://github.com/arjensuijker/all-in-one-publishing/commits/master		Of course the process wasn't as linear as it appears here. The process can be better described as being '''iterative, looping through the steps''' continuously. The commits list in github can be a good portrait of this iteration. Available at: https://github.com/arjensuijker/all-in-one-publishing/commits/master

	== Challenges ==		== Challenges ==
Line 30:		Line 30:

	=== Cleaning up the HTML ===		=== Cleaning up the HTML ===
	In Word, there are basically two methods to style a document: using styles or by manually changing the font properties for every heading and paragraph. The first method results in html files with a better (semantic) structure, because the styles can directly translated to HTML tags. The second method creates very messy HTML files that require lots of cleaning because the HTML is littered with unnecessary styling information. The documents that we used as the source were somewhere in between: most styling was done correctly, but a lot of manual cleaning was still needed. Additionally, most figures had to be extracted manually.		In Word, there are basically two methods to style a document: '''using styles or by manually changing the font properties''' for every heading and paragraph. The first method results in html files with a better (semantic) structure, because the styles can directly translated to HTML tags. The second method creates very messy HTML files that require lots of cleaning because the HTML is littered with unnecessary styling information. The documents that we used as the source were somewhere in between: most styling was done correctly, but a lot of manual cleaning was still needed. Additionally, most '''figures had to be extracted manually'''.

	=== Adding semantic structure and classes ===		=== Adding semantic structure and classes ===

Arjensuijker at 07:01, 24 September 2015

2015-09-24T07:01:27Z

← Older revision		Revision as of 07:01, 24 September 2015
Line 1:		Line 1:
	== Introduction ==		== Introduction ==

	The core of our research is the development a workflow in which HTML and CSS files are used as the primary source for a publication. This publication is then made available for print, epub and a responsive website. This approach was chosen because it can potentially improve the publication workflow for the following reasons:		The core of our research is the development of '''a workflow in which HTML and CSS''' files are used as the '''primary source for a publication'''. This publication is then made available for print, epub and a responsive website. This approach was chosen because it can potentially improve the publication workflow for the following reasons:

	* Both the design and the content can be updated at any time, fully independently of each other.		* Both the '''design and the content can be updated at any time''', fully independently of each other.
	* Every update in content or design can be exported to every available publication medium.		* '''Every update''' in content or design can be exported to '''every available publication medium'''.
	* HTML and CSS are very widespread transparent file formats that have been used for decades without much change, and will remain this way for years to come. This makes them much more suitable for digital archiving than most proprietary formats.		* '''HTML and CSS are very widespread transparent file formats''' that have been used for decades without much change, and will remain this way for years to come. This makes them much more suitable for '''digital archiving''' than most proprietary formats.
	* For largely the same reasons, the resulting publication is very suitable for (collaborative) reuse and redesign.		* For largely the same reasons, the resulting publication is very '''suitable for (collaborative) reuse and redesign'''.

	=== About the process ===		=== About the process ===

Arjensuijker at 07:35, 9 July 2015

2015-07-09T07:35:56Z

← Older revision		Revision as of 07:35, 9 July 2015
Line 41:		Line 41:

	==== Web CSS ====		==== Web CSS ====
	For the website, the whole design of the book had to be reimagined. Pages do not exist, information doesn't have to be linear and many interactive posibilities open up. We decided to keep the website largely linear because it seemed to fit the content well. Some interactivity was added: the index was redesigned to become a navigation menu and the footnotes were made into toolips. Because the font (Metric) was not licensed for online use, we had to find a font that was similar. This proved to be very difficult, so we had to compromise. We tried to avoid using javascript when possible, as this can decrease compatibility and increase the complexity of the code. The only exception we made was for the footnotes, because this was simply not possible in CSS. Numbering of figures, pages and tables was also done in CSS. This turned out to work out quite well, although browser support is somewhat limited.		For the website, the whole design of the book had to be reimagined. Pages do not exist, information doesn't have to be linear and many interactive posibilities open up. We decided to keep the website largely linear because it seemed to fit the content well. Some interactivity was added: the index was redesigned to become a navigation menu and the footnotes were made into toolips. Because the font (Metric) was not licensed for online use, we had to find a font that was similar. This proved to be very difficult, so we had to compromise. We tried to avoid using javascript when possible, as this can decrease compatibility and increase the complexity of the code. The only exception we made was for the footnotes, because this was simply not possible in CSS. Numbering of figures, pages and tables was also done in CSS. This turned out to work out quite well, although browser support is somewhat limited. At a later stage we realized that this may not have been the optimal solution, since this numbering is vital information and not just a matter of styling.

	==== Responsive web CSS ====		==== Responsive web CSS ====

Lucia Dossin: /* Responsive web CSS */

2015-07-08T09:03:10Z

Responsive web CSS

← Older revision		Revision as of 09:03, 8 July 2015
Line 44:		Line 44:

	==== Responsive web CSS ====		==== Responsive web CSS ====
	Instead of creating a separate mobile output, we made the regular website responsive to screen size. The challenges we encountered while doing this were not much different from the challenges that come with all mobile websites. Even though these challenges also belong to our research topic, they do not represent the most innovative aspects of it. For this reason, documentation regarding this output seems redundant.		Instead of creating a separate mobile output, we made the regular website responsive to screen size. The challenges we encountered while doing this were not much different from the challenges that come with all mobile websites. Even though these challenges also belong to our research topic, they do not represent the most innovative aspects of it. For this reason, documentation regarding this output seems redundant to us.

	==== Epub CSS ====		==== Epub CSS ====

Lucia Dossin: /* Responsive web CSS */

2015-07-08T09:02:35Z

Responsive web CSS

← Older revision		Revision as of 09:02, 8 July 2015
Line 44:		Line 44:

	==== Responsive web CSS ====		==== Responsive web CSS ====
	Instead of creating a separate mobile output, we made the regular website responsive to screen size. The challenges we encountered while doing this were not much different from the challenges that come with all ~~responsive~~ websites. ~~Since~~ these challenges ~~are already well-documented~~, ~~we will~~ not ~~discuss these further~~.		Instead of creating a separate mobile output, we made the regular website responsive to screen size. The challenges we encountered while doing this were not much different from the challenges that come with all mobile websites. Even though these challenges also belong to our research topic, they do not represent the most innovative aspects of it. For this reason, documentation regarding this output seems redundant.

	==== Epub CSS ====		==== Epub CSS ====

Lucia Dossin: /* Web CSS */

2015-07-08T08:52:00Z

Web CSS

← Older revision		Revision as of 08:52, 8 July 2015
Line 41:		Line 41:

	==== Web CSS ====		==== Web CSS ====
	For the website, the whole design of the book had to be reimagined. Pages do not exist, information doesn't have to be ~~lineair~~ and many interactive posibilities open up. We decided to keep the website largely ~~lineair~~ because seemed to fit the content well. Some interactivity was added: the index was redesigned to become a navigation menu and the ~~tooltips~~ were made into toolips. Because the font (Metric) was not licensed for online use, we had to find a font that was similar. This proved to be very difficult, so we had to compromise. We tried to avoid using javascript when possible, ~~because~~ this can decrease compatibility and increase the complexity of the code. The only exception we made was for the footnotes, because this was simply not possible in CSS. Numbering of figures~~, footnotes~~, pages and tables was also done in CSS. This turned out to work out quite well, although browser support is somewhat limited.		For the website, the whole design of the book had to be reimagined. Pages do not exist, information doesn't have to be linear and many interactive posibilities open up. We decided to keep the website largely linear because it seemed to fit the content well. Some interactivity was added: the index was redesigned to become a navigation menu and the footnotes were made into toolips. Because the font (Metric) was not licensed for online use, we had to find a font that was similar. This proved to be very difficult, so we had to compromise. We tried to avoid using javascript when possible, as this can decrease compatibility and increase the complexity of the code. The only exception we made was for the footnotes, because this was simply not possible in CSS. Numbering of figures, pages and tables was also done in CSS. This turned out to work out quite well, although browser support is somewhat limited.

	==== Responsive web CSS ====		==== Responsive web CSS ====

Lucia Dossin: /* About the process */

2015-07-08T08:47:55Z

About the process

← Older revision		Revision as of 08:47, 8 July 2015
Line 10:		Line 10:
	=== About the process ===		=== About the process ===

	For this research, we have chosen to take an existing publication and explore how it could be rebuilt from scratch using our newly developed workflow. The original publication was only designed for print. Our ~~goals~~ was to replicate this design as closely as possible with our new print version, and adapt the design to also fit the other media.		For this research, we have chosen to take an existing publication and explore how it could be rebuilt from scratch using our newly developed workflow. The original publication was only designed for print (a pdf). Our goal was to replicate this design as closely as possible with our new print version, and adapt the design to also fit the other media.

	The global process consisted of the following steps:		The global process consisted of the following steps:

	# The original Word documents with the contents of the publication were converted to html files using ~~pandoc~~ conversion software.		# The original Word documents with the contents of the publication were converted to html files using Pandoc conversion software.
	# These html files were 'cleaned up', deleting everything design-related and only ~~leaving~~ structural information.		# These html files were 'cleaned up', deleting everything design-related and leaving only structural information.
	# Additional HTML was added to improve semantic value and facilitate CSS styling.		# Additional HTML was added to improve semantic value and facilitate CSS styling.
	# CSS stylesheets were created for every output format.		# CSS stylesheets were created for every output format.
	# The outputs were created and tested using Pandoc (for epub), PrinceXML and Weasyprint (for pdf), Chrome (for ~~reposponsive~~ web) and Firefox (for direct browser print) and checked for consistency. PrinceXML is proprietary software, Weasyprint is not.		# The outputs were created and tested using Pandoc (for epub), PrinceXML and Weasyprint (for pdf), Chrome (for responsive web) and Firefox (for direct browser print) and checked for consistency. PrinceXML is proprietary software, Weasyprint is not.

	Of course the process wasn't as linear as it appears here. The process can be better described as being iterative, looping through the steps continuously. The commits list in github can be a good portrait of this iteration. Available at: https://github.com/arjensuijker/all-in-one-publishing/commits/master		Of course the process wasn't as linear as it appears here. The process can be better described as being iterative, looping through the steps continuously. The commits list in github can be a good portrait of this iteration. Available at: https://github.com/arjensuijker/all-in-one-publishing/commits/master

Lucia Dossin: /* Cleaning up the HTML */

2015-07-08T08:45:34Z

Cleaning up the HTML

← Older revision		Revision as of 08:45, 8 July 2015
Line 30:		Line 30:

	=== Cleaning up the HTML ===		=== Cleaning up the HTML ===
	In ~~word~~, there are basically two methods to style a document: using styles or by manually changing the font properties for every heading and paragraph. The first method results in html files with a ~~great~~ structure, because the styles can directly translated to HTML tags. The second method creates very messy HTML files that require lots of cleaning because the HTML is littered with unnecessary styling information. The documents that we used as the source were somewhere in between: most styling was done correctly, but a lot of manual cleaning was still needed. Additionally, most figures had to be extracted manually.		In Word, there are basically two methods to style a document: using styles or by manually changing the font properties for every heading and paragraph. The first method results in html files with a better (semantic) structure, because the styles can directly translated to HTML tags. The second method creates very messy HTML files that require lots of cleaning because the HTML is littered with unnecessary styling information. The documents that we used as the source were somewhere in between: most styling was done correctly, but a lot of manual cleaning was still needed. Additionally, most figures had to be extracted manually.

	=== Adding semantic structure and classes ===		=== Adding semantic structure and classes ===